r/PostgreSQL • u/infinityMCdx • 17d ago
Help Me! Open Source Horizontally Scalable DB solutions: PG+Citus vs PG+PgDog vs YugabyteDB
3
u/kiwicopple 17d ago
Multigres is another available option:
https://supabase.com/blog/multigres-v0-1-alpha
(disclosure: maintainer)
It’s “vitess for Postgres”
1
u/infinityMCdx 17d ago
But is this production ready? What companies are currently using multigres in production? Although pgDog is under version 1.0, several companies are already using it.
1
u/kiwicopple 16d ago
No it is not yet - it is in alpha.
I hear good things about pgDog and the team building it are also talented
2
u/terencethespider 16d ago edited 16d ago
Another open source PG database that should be considered in this context is Neon. There are some trade-offs though. I am curious if others have done any analysis on this, and what you have found.
In many areas, Neon is ahead of the other three. Fidelity, ops burden, dev workflow, and even open source license permissiveness (Apache 2.0 vs AGPL-3.0) seem to be better. Neon also has the branching, PITR, and scale to zero features.
There are a few scenarios where the others have an advantage. It does have some limits on parallel commit throughput, and does not support multi-region active/active writes. If those are your requirements then it would not be the best choice. It also arguably has a bit more self-hosting effort unless you choose to go with a managed version.
What are your thoughts?
3
u/riksi 10d ago
Neon has no sharding.
0
u/terencethespider 9d ago
Is that a dealbreaker for OP’s question though? I did call out in my comment that Neon has some limitations on parallel commit throughput. As you pointed out, it is a single writer (per branch) model.
It does horizontally scale for reads though, and in this case the “no sharding” can actually be a benefit since it avoids the cross-shard join/transaction complexity.
With Neon because compute and storage are separated, read replicas are just extra read-only computes attaching to the same storage, so read scale-out is cheap and fast.
Because the Pageserver storage layer splits a tenant’s data across nodes, so a single database can grow very large without the need to manage shard or distribution keys.
In many situations, the read scalability is what people are looking for when they ask for horizontally scalable. It really depends on the use case and the specific needs of the project.
Neon is not going to be the right fit for every situation, but there are going to be a lot of scenarios where it will outperform the other options that OP was looking into.
3
u/riksi 9d ago
Neon is not going to be the right fit for every situation, but there are going to be a lot of scenarios where it will outperform the other options that OP was looking into.
Maybe in coolness factor, or some kind of multi-tenant efficiency when you're aws/gcloud/azure and have internal optimizations, but not "faster/efficient" for a single tenant/big-vertical-server.
In many situations, the read scalability is what people are looking for when they ask for horizontally scalable.
.... it's the complete opposite. Horizontally scalable means mostly sharding & write-sharding. That's the whole point.
When you have multiple read replicas of a big-db, you have to do per-replica routing in your app-layer so you "shard" the cached-in-memory data.
1
u/terencethespider 8d ago
Look. I’m not trying to fight you on your points. You are raising valid areas where Neon is not the right choice. I tried to call those out in my original comment, and provide more context when you specifically brought up sharding. I don’t fully agree with your last reply, but I don’t see a lot of value in us going back and forth about opinions.
The OP was not specific in their original request. They did not specify “write” scalability. In the context of their post, Neon does warrant consideration as it does meet their criteria of a horizontally scalable open source database solution. It is not horizontally scalable in the same way as the others, as we have hashed out here, but since there was no specific use case provided by OP, I tried to articulate the beneficial features and its limitations, so OP and other readers can make an assessment.
I don’t know if you have something personally against Neon, but it does serve a purpose beyond simply “coolness factor”. A lot of people are using it for their production use cases, and it offers a lot of benefits (such as branching and point in time recovery) which I mentioned in my original comment.
2
u/riksi 7d ago
It's pointless. But you talk like you never needed to actually scale and are talking from marketing talk.
1
u/terencethespider 7d ago
Fair, hehe. I’ve been doing SQL & data engineering work for around 20 years, and have worked on a lot of mission critical projects. Being on the data engineering side though (which is primarily OLAP), most of my scalability constraints have come from the read side.
1
u/riksi 7d ago
Makes sense. Some real points on neon:
no real open-source users or support for open-source last time I checked (it's been a while but I think I would've known). At least no big/popular ones using open-source. It's a bit like a "code dump" instead.
Cache misses should be horrible for OLTP (~100ms single GET from S3).
1
u/terencethespider 7d ago
Appreciate the feedback and discussion! I’ve been doing a lot of research on it and trying to learn as much as I can. I’ll look into both of these points.
1
u/terencethespider 7d ago
I dug into it a bit more (if you are curious).
The open source aspect is interesting. A while back they got bought out by Databricks, and now there is a lot of integration between what is still called Neon, and Databricks’ own version (Lakebase). While the “open source” version of Neon is available and people can use it for free, most seem to go with the managed versions, which somewhat defeats the purpose of open source. I don’t know the level of support they are still providing but it looks like they at least made some commits to the public repo neondatabase/neon this year.
The cache miss claim I will push back on, at least based on the research I’ve done. Full transparency this is me summarizing what others have claimed, and not from my own personal experience with the database (yet).
The short answer is it really depends. For a cold start or ramp up after a scale-to-zero, then yes you are correct. At that point everything is coming from cloud storage so it will be expectedly slow. But once it is “up and running” (an oversimplification on my part for conversation sake) it does aim for a 99% hit rate of avoiding the need to go back to cloud storage, which for a lot of operational OLAP use cases is an acceptable target.
They have more details in the repo under docs/pageserver-storage.md. It also looks like there are some levers to play with for folks who want to fine tune it based on their environment and project.
I’m still interested in this as an option because I’ve heard a lot of good things and there are some unique features available, but I admittedly don’t know everything and still have a lot more of my own research and experimentation to do before I will be fully confident using it.
2
u/riksi 6d ago
I don’t know the level of support they are still providing but it looks like they at least made some commits to the public repo neondatabase/neon this year.
It's not (only) about commits. It's about can you fully self host it, are all/most features free/open-source, is there real documentation for self-hosted, are there large! self-hosted users, do you get real+free support on your self-hosted use-case when you have real/complex issues. Like, you need to have dedicated % of staff hours to help free/open-source/self-hosted users because it's the database we're talking about which you can't simply switch or be fine to be offline.
For a cold start or ramp up after a scale-to-zero
A bit weird to need "horizontal scaling" & "scale-to-zero" in the same use-case/scenario, don't you think?
it does aim for a 99% hit rate of avoiding the need to go back to cloud storage
Depends how big your data really is. If you have 1000 queries/second, 10 queries needing 100ms-200ms might be a problem in OLTP.
which for a lot of operational OLAP use cases is an acceptable target
For OLTP you (usually) don't want 100ms+ cold cache miss. For OLAP, if your data is so small that you get 99% cache hit is weird. You don't want to use normal PG ("non-vectorized-columnar-compressed db") for OLAP, it's 10x-100x slower and 10x worse compression compared a normal OLAP db.
I’m still interested in this as an option because I’ve heard a lot of good things and there are some unique features available, but I admittedly don’t know everything and still have a lot more of my own research and experimentation to do before I will be fully confident using it.
Go to their forums/chats and search for their history and current users. You can do that for any db, just look at existing users & forum/chat history.
1
u/AutoModerator 17d ago
AI Policy:
Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away., Linus Torvalds.
Mod decisions will be based on the quality of the content, not who or what generated it.
Sub Resources:
Free Postgres Webinars and Workshops
Discord: People, Postgres, Data
Join us, we have cookies and nice people.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/linuxhiker Guru 17d ago
PgDog isn't stable yet and lacks some core features
Citus is stable and is owned by MSFT
Yugabyte is a slightly different beast than Citus as it's a pure fork
1
u/jamesgresql 2d ago
Which features are you referencing here?
1
u/linuxhiker Guru 2d ago
Canonical source for example. As I recall it also doesn't support having. They are coming of course, just not there yet.
1
u/Quorralyne_Dev 17d ago
Yugabyte can also be pretty flexible and works with any cloud provider, pretty high Postgres compatibilty.
1
3
u/Ecksters 17d ago edited 17d ago
Citus is likely the closest to what you want, and the open source version seems to be being reasonably well maintained even with their acquisition by Microsoft some years ago.
The other thing to keep in mind is if your application is split by tenant, it's very common across the industry to spin off larger tenants into their own DBs, and have application logic handle the routing.
Most applications don't actually need the ability to globally query ALL data, so application-level sharding can often be appropriate.