ppg-proxy series - proposal doc#7996
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
| 2. justifying the need for a "proxy" or "gateway": what responsibilities it takes: | ||
| - route postgres traffic to the target databases, preserving tenant isolation | ||
| - better auth scheme, api-key based, rotation without touching db credentials | ||
| - billing & holds based on queries, ingress/egress traffic, backup traffic, etc | ||
| - unified throttling, observability, access logging |
There was a problem hiding this comment.
The gateway will also give us a mechanism to cordon of the PPg hosts entirely from public traffic, which will be a huge security/maintenance win.
| 3. Chanllenges and how we overcome them | ||
| - the routing data distribution: choices and tradeoffs | ||
| - The postgres binary protocol (message-oriented) and the open source libraries landscape | ||
| - buffering and the noisy neighbor problem: when horizontal scaling hides but doesn't solve the problem | ||
| - biting the bullet and implementing a full end-to-end low level streaming protocol capability, while still allowing selective messages inspection (e.g. error reporting or query counting) |
There was a problem hiding this comment.
Do you want to put our logging-to-stdout adventure in here too or nah 😆
| - lack of support for native tcp/tls client connectivity (sometimes) | ||
| - possible approaches to bridge the gap: dedicated pooler, http/ws protocol wrapper, or pooler-as-a-service (accelerate, which does both things with its limitations) | ||
| 2. Tackling the throwaway-connection issue with pooling | ||
| - what's connection pooling, what's its main goal (to relieve pressure on the db for connection creation/teardown) |
There was a problem hiding this comment.
Another fun one here could be something about its non-goals, like query performance or latency, and why adding a pooler will actually slow you down sometimes.
| A proposal for a series of blogposts showing how we manage prisma postgres connectivity, discussing about the ppg-proxy, what problems it resolves, how it evolved, the challenges whe faced over time, and the revamp that we've been doing as a result. | ||
|
|
||
|
|
||
| # 1 ppg-proxy intro: what, why and how |
| - A detour on fakepg and why we need it (testing connectivity issues, or just sequences of pre-baked messages) | ||
| 3. What's next | ||
| - Connection Pooling as a 2-facet system: the protocol sensing and the connection factory | ||
| - The plan to support advanced pooling features (first we do query detection, transaction boundary and then detecting unsupported statement as the last thing) |
There was a problem hiding this comment.
@pcan here's some feedback from me and GPT:
High-level structural feedback
-
The series has strong raw material, but the structure is currently too implementation-led. It reads more like an internal architecture history than a public-facing blog series.
-
The reader needs a clearer “why should I care?” arc before getting deep into protocol internals.
-
Start with the developer/customer problem, not
ppg-proxy.- “ppg-proxy intro: what, why and how” is accurate, but not very compelling as the entry point.
- A stronger frame would be something like: “How Prisma Postgres handles secure, scalable database connectivity.”
- Then introduce
ppg-proxyas the system that makes that possible.
Narrative arc
Right now, the progression feels like:
proxy → pooling → HTTP/WS → revamp
A stronger arc would be:
developer pain → platform constraints → connectivity architecture → serverless access → protocol/streaming design → unified future architecture
That gives the series a clearer reader-facing story instead of making it feel like a chronological engineering history.
Audience clarity
The intended audience is currently unclear. Some parts speak to app developers, some to infra engineers, and some to Prisma employees.
I’d decide whether the series is primarily for:
- Prisma users who want to understand Postgres connectivity
- backend/platform engineers interested in architecture
- database/protocol nerds
My recommendation: target senior backend/platform engineers, but always anchor each post in user-visible product value.
Series-level recommendations
-
Each post needs a sharper promise. Before the outline, add one sentence per post answering: “After reading this, the reader will understand X.”
-
Separate product value from engineering war stories.
- The logging-to-stdout adventure, noisy neighbor issues, protocol rewrites, and
fakepgare great. - But they should only appear where they support the main reader-facing point.
- Otherwise, the series risks feeling like an internal postmortem.
- The logging-to-stdout adventure, noisy neighbor issues, protocol rewrites, and
-
The proposal should define success for the series:
- Is this meant to build trust in Prisma Postgres?
- Explain serverless connectivity?
- Recruit infra talent?
- Support launch messaging?
-
The structure should change depending on that goal.
Post 1: ppg-proxy intro
- The first post is overloaded.
- It tries to explain Prisma Postgres, multi-tenancy, routing, auth, billing, throttling, observability, protocol challenges, buffering, noisy neighbors, and future plans.
- That is too much for an intro.
- Keep the intro focused on the gateway’s purpose and the core problems it solves.
Post 1 should establish the system boundary clearly:
- Is
ppg-proxya gateway? - A TCP proxy?
- An auth layer?
- A routing layer?
- A metering point?
- An observability boundary?
- All of the above?
The outline lists responsibilities, but the reader needs a mental model early.
Also, the security angle should be promoted. The point about cordoning off Prisma Postgres hosts from public traffic is a big value point. That should not be a side note. It belongs in the main structure of post 1 because it makes the gateway feel necessary, not incidental.
The billing/metering point also needs careful placement. “Billing & holds based on queries, ingress/egress traffic, backup traffic” is important internally, but for an external audience it may feel vendor-centric. I’d frame it as:
- accurate usage visibility
- fair resource accounting
- abuse protection
- operational safety
Post 2: serverless connection pooling
-
Post 2 is the clearest structurally.
-
The connection pooling post has a strong shape already:
- problem
- explanation
- tradeoffs
- Prisma Postgres approach
This is probably the best-structured outline in the proposal.
I’d add explicit non-goals to the pooling post. The review comment is spot on:
- pooling does not magically make queries faster
- pooling can add latency in some cases
- pooling mainly helps with connection lifecycle pressure, not query performance itself
That will make the post more trustworthy.
Also, avoid making the serverless intro too generic. “What are serverless workloads?” can easily become a 101 section readers skip. Keep it short and tie it directly to database connectivity:
- short-lived processes
- connection storms
- missing TCP support
- transaction semantics
- persistent database connections vs ephemeral compute
Post 2 and Post 3 overlap
Post 2 and Post 3 both talk about serverless constraints and bridging TCP/TLS gaps.
I’d make the distinction explicit:
- Post 2: connection lifecycle pressure
- Post 3: transport/protocol limitations
That separation will help the series feel intentional instead of repetitive.
Post 3: HTTP/WS API and driver
-
Post 3 currently sounds too competitor-comparative.
-
The Neon case study could be useful, but “poor/short-sighted model” reads unnecessarily spicy and may distract from Prisma’s own design.
-
A better structure would be:
- explain common industry approaches
- describe their tradeoffs
- show why Prisma chose a streaming-first design
Be careful with Data Proxy / Accelerate framing too. Lessons learned from past Prisma systems are valuable, but avoid making existing Prisma products sound broken. I’d frame it as:
What we learned from operating query engines and managed proxies at scale.
Post 3 has the strongest technical hook: streaming. That should be the centerpiece.
The outline should lead with:
- why request/response breaks down
- why streaming matters
- what a streaming-first serverless Postgres API unlocks
The driver section risks becoming too broad. “A driver for every language” and JDBC examples are interesting, but they may belong in a future-looking closing section, not a major structural pillar. Keep the post centered on the API/driver contract.
Post 4: ppg-proxy revamped
- Post 4 is too dense and too internal.
- It contains many important pieces, but it currently reads like an architecture planning document.
- For a blog post, I’d split or simplify it.
- The reader needs fewer moving parts and a more explicit payoff.
Post 4 needs a clearer before/after structure:
- Before: TCP proxy and serverless API evolved separately.
- Problem: duplicated protocol handling, inconsistent lifecycle logic, harder pooling.
- After: unified protocol pipeline with terminal adapters.
- Benefit: better pooling, testing, streaming, maintainability, and future features.
The current outline also buries one of the most interesting architectural ideas:
Connection lifecycle and protocol handling are separate problems.
That is a strong conceptual takeaway and should be promoted earlier in Post 4.
A few specific notes:
- “AI-accelerated re-architecting” feels out of place unless it is central to the post. It risks aging badly and distracting from the actual architecture.
fakepgshould be a sidebar, not a main detour. It sounds fascinating, but structurally it can derail the post. Use it as a concrete testing example after the main architecture is already clear.
Titles
The titles need work. They are descriptive but not reader-oriented.
“ppg-proxy for serverless - part 1” feels internal. I’d use titles that describe the problem/value instead:
- Why Prisma Postgres needs a gateway
- Why serverless apps are hard on Postgres connections
- Designing a streaming API for serverless Postgres
- Unifying TCP and serverless connectivity in Prisma Postgres
Suggested repeated structure
The outline would benefit from a repeated structure across posts:
- User/platform problem
- Why the obvious solution breaks down
- Prisma’s approach
- Tradeoffs and lessons learned
- What this unlocks next
This would make each post easier to write and easier to follow.
Article endings
Each post should end with a concrete takeaway, not just “what’s next.”
The “what’s next” sections are useful, but each article should close with what the reader should now understand.
Jargon
There is a lot of jargon without staged explanation.
Terms like these are fine for the audience, but they should be introduced progressively:
- ingress layer
- framing
- flow control
- terminal adapters
- clean/busy/dirty connections
- transaction boundary detection
pgproto3- sub-message streaming
Overall recommendation
Keep the four-part series, but reframe it from:
Here is how ppg-proxy evolved.
to:
How Prisma Postgres is building a secure, serverless-friendly connectivity layer for Postgres.
That makes the series more valuable to external readers while still giving engineering enough room to go deep.
3 participants
No description provided.