Making Postgres scale

https://pgdog.dev/blog/you-can-make-postgres-scale

by levkk • 1 year ago

225 188 1 year ago

I'm kind of interested in why we can't make a better database with all of our modern technology.

Postgres is a fantastic workhorse, but it was also released in the late 80s. Who, who among you will create the database of the future... And not lock it behind bizarro licenses which force me to use telemetry.

trescenzi• 1 year ago

I guess I’d ask why is something having been first released in the late 80s, or any decade, as positive or negative? Some things are still used because they solve the problems people have. Some things are still used just because of industry capture. I’m not honestly sure where I’d put Postgres.

Are there specific things you’d want from a modern database?

9999000009997• 1 year ago

Relating to the article, better scaling. Saying run it on a bigger box is a very brute force way to optimize an application.

While they come up with some other tricks here, that's ultimately what's scaling postgres means.

If I imagine a better database, it would have native support for scaling, a postgres compatible data layer as well as first party support for NoSQL( JSONB columns don't cut it since if you have simultaneous writes unpredictable behavior tends to occur).

It needs to also have a permissible license

DoctorOW• 1 year ago

Have you looked at CockroachDB? PostgreSQL compatibility with modern comforts (e.g. easy cloud deployments, horizontal scaling, memory safe language)

rednafi11• 1 year ago

Came here to say this. Cockroach solves the sharding issue by adopting consistent hashing-based data distribution, as described in the Dynamo paper. However, their cloud solution is a bit expensive to get started with.

HighlandSpring• 1 year ago

There are "better" databases but they're better given some particular definition that may not be relevant to your needs. If SQL/the relational model and ACID semantics is what you need then postgres is simply the best in class. The fact it dates back to the 80s is probably an advantage (requirement?) when it comes to solving a problem really well

wmf• 1 year ago

Anyone who creates a better database is going to want to get paid for it which either means DBaaS or those weird licenses.

thinkingtoilet• 1 year ago

Postgres 17.4 was released last month. Show some respect to the devs.

HDThoreaun2• 1 year ago

Postgres is the most worked on database in the world right now. Its original release date doesnt mean work stopped. No-sql was a new thing a decade-ish ago but most companies probably dont need it. New data platforms focused on scaling like snowflake and cockroach have come too but again for most use cases postgres is better.

moltar• 1 year ago

Look at AWS presentation/talk about Aurora DSQL [1]

It’s a Postgres facade. But everything beyond that is a complete reimagining and a rewrite to scale independently.

I personally think it’s going to eat a lot of market share when it solves some remaining limitations.

[1] https://youtu.be/huGmR_mi5dQ?si=ALw4XjdDJBxkZWRv

remram• 1 year ago

Never heard of pgdog before. How does it compare to citus?

MuffinFlavored• 1 year ago

What are the drawbacks of Citus/why isn't it perfect/what would you look for from a competitor/alternative?

craigkerstiens2• 1 year ago

Citus works really well *if* you have your schema well defined and slightly denormalized (meaning you have the shard key materialized on every table), and you ensure you're always joining on that as part of querying. For a lot of existing applications that were not designed with this in mind if can be several months of database and application code changes to get things into shape to work with Citus.

If you're designing from scratch and make it worth with Citus then (specifically for a multi-tenant/SaaS sharded app) it can make scaling seem a bit magical.

caffeinated_me4• 1 year ago

Seems like this is a similar philosophy, but is missing a bunch of things the Citus coordinator provides. From the article, I'm guessing Citus is better at cross-shard queries, SQL support, central management of workers, keeping schemas in sync, and keeping small join tables in sync across the fleet, and provides a single point of ingestion.

That being said, this does seem to handle replicas better than Citus ever really did, and most of the features it's lacking aren't relevant for the sort of multitenant use case this blog is describing, so it's not a bad tradeoff. This also avoids the coordinator as a central point of failure for both outages and connection count limitations, but we never really saw those be a problem often in practice.

levkk12• 1 year ago

We certainly have a way to go to support all cross-shard use cases, especially complex aggregates (like percentiles). In OLTP, where PgDog will focus on first, it's good to have a sharding key and a single shard in mind, 99% of the time. The 1% will be divided between easy things we already support, like sorting, and slightly more complex things like aggregates (avg, count, max, min, etc.), which are on the roadmap.

For everything else, and until we cover what's left, postgres_fdw can be a fallback. It actually works pretty well.

levkk12• 1 year ago

Great question and we will publish something for this later on. TLDR: Citus doesn't provide an easy migration path for existing DBs and the managed deployments are pretty much exclusive to Azure. A large percentage of production DBs run elsewhere and don't have an easy way to shard.

craigkerstiens2• 1 year ago

Probably as useful is the overview of what pgdog is and the docs. From their docs[1]: "PgDog is a sharder, connection pooler and load balancer for PostgreSQL. Written in Rust, PgDog is fast, reliable and scales databases horizontally without requiring changes to application code."

[1] https://docs.pgdog.dev/

saisrirampur• 1 year ago

Interesting technology. Similar to Citus but not built as an extension. The Citus coordinator, which is a Postgres database with the Citus extension, is replaced by a proxy layer written in Rust. That might provide more flexibility and velocity implementing distributed planning and execution than being tied to the extension ecosystem. It would indeed be a journey to catch up with Postgres on compatibility, but it's a good start.

sroussey• 1 year ago

So like the MySQL proxies of long ago?

There are definitely advantages of not running inside the system you wish to orchestrate.

Better keep up with the parser though!

levkk12• 1 year ago

We use the Postgres parser directly, thanks to the great work of pg_query [1].

[1] https://github.com/pganalyze/pg_query.rs

mindcrash3• 1 year ago

Well, ofcourse it does! :)

Another (battle tested * ) solution is to deploy the (open source) Postgres distribution created by Citus (subsidiary of Microsoft) on nodes running on Ubuntu, Debian or Red Hat and you are pretty much done: https://www.citusdata.com/product/community

Slap good old trusty PgBounce in front of it if you want/need (and you probably do) connection pooling: https://www.citusdata.com/blog/2017/05/10/scaling-connection...

*) Citus was purchased by Microsoft more or less solely to provide easy scale out on Azure through Cosmos DB for PostgreSQL

gigatexal• 1 year ago

Is it really that easy? What are the edge cases?

levkk12• 1 year ago

It's not. We tried. Plus, it doesn't work on RDS, where most of production databases are. I think Citus was a great first step in the right direction, but it's time to scale the 99% of databases that don't run on Azure Citus already.

caffeinated_me4• 1 year ago

Depends on your schema, really. The hard part is choosing a distribution key to use for sharding- if you've got something like tenant ID that's in most of your queries and big tables, it's pretty easy, but can be a pain otherwise.

rohan_• 1 year ago

Couldn't they have just moved to Aurora DSQL and saved all the headache?

levkk12• 1 year ago

We actually found Aurora to be about 3x slower than community PG for small queries. That was back then, maybe things are better now. Migrating to another database (and Aurora is Postgres-compatible, it's not Postgres) is very risky when you've been using yours for years and know where the edge cases are.

rednafi11• 1 year ago

This!

Postgres to pg-compatible DBs are never as smooth as they advertise it to be.

sgarland8• 1 year ago

I’ve consistently found Aurora MySQL and PG to be slower than everything, including my 12 year old Dell R620s. You can’t beat data locality, and the 4/6 quorum requirement of Aurora combined with the physical distance kills any hope of speed.

SahAssar2• 1 year ago

Aurora is postgres but with a different storage layer, no? It uses the postgres engine, which other postgres-compatible databases like cockroach do not, right?

re-thc2• 1 year ago

Aurora DSQL

There isn't even pricing on it...

fmajid2• 1 year ago

Skype open-sourced their architecture way back, using PL/Proxy to route calls based on shard. It works, is quite elegant, handled 50% of all international phone calls in the noughties. My old company used it to provide real-time analytics on about 300M mobile devices.

https://wiki.postgresql.org/images/2/28/Moskva_DB_Tools.v3.p...

https://s3.amazonaws.com/apsalar_docs/presentations/Apsalar_...

Keyframe2• 1 year ago

Skype has had from the beginning the requirement that all database access must be implemented through stored procedures.

That presentation starts with hard violence.

Tostino2• 1 year ago

If the database team designed a thoughtful API with stored procedures, this can actually be a quite nice way to interact with a database for specific uses.

Being 100% hard and fast on that rule seems like a bad idea though.

sgarland8• 1 year ago

I would much rather this than letting devs write their own queries, ORM or not. But then, I own the DBs, and I am constantly dealing with the result of poor schema and query decisions.

fmajid2• 1 year ago

Righteous violence.

One of the benefits of stored procedures they don't mention is SECURITY DEFINER, which is like setuid.

You can for instance have a user table with login and hashed password, have a stored procedure that can verify login and password, without giving SELECT access to the user table to the database user your application use.

Stored procedures also block SQL injection attacks.

rednafi11• 1 year ago

Another option is going full-scale with CockroachDB. We had a Django application backed by PostgreSQL, which we migrated to CockroachDB using their official backend.

The data migration was a pain, but it was still less painful than manually sharding the data or dealing with 3rd party extensions. Since then, we’ve had a few hiccups with autogenerated migration scripts, but overall, the experience has been quite seamless. We weren’t using any advanced PostgreSQL features, so CockroachDB has worked well.

skunkworker• 1 year ago

Unless their pricing has changed, it’s quite exorbitant when you need a lot of data. To the point that one year of cockroachdb would cost 5x the cost of the server it was running on.

rednafi11• 1 year ago

This is still true. I wouldn’t use Cockroach if it were my own business. Also, they don’t offer any free version to try out the product. All you get is a short trial period and that’s it.

CharlesW2• 1 year ago

I think you're referring to the CockroachDB Cloud DBaaS offering vs. CockroachDB itself, correct?

levkk12• 1 year ago

I'm glad you brought up the migration, because one of the main goals behind our project is to automate migrating to a sharded deployment. You can think of your DB as the base case (num_shards = 1), and PgDog as the recursive solution.

rednafi11• 1 year ago

Automatic data transfer would be super cool to get out of the box. We had a custom multi-tenancy solution for our application that heavily used PostgreSQL schemas. One schema for each customer.

It was a pain to get that work with Cockroach since it doesn’t optimize cross schema queries and suggests one DB per customer. This was a deal breaker for us and we had to duplicate data to avoid cross schema queries.

Being able to live within Postgres has its advantages.

traceroute66• 1 year ago

Another option is going full-scale with CockroachDB

Just beware that CockroachDB is not a drop-in replacement for PostgreSQL.

Last time I looked it was missing basic stuff. Like stored functions. I don't call stored functions an "advanced feature".

frollogaston5• 1 year ago

I also wonder what limitations you get on queries. Cause in Spanner, there's something about cross-directory queries, or Citus can't do cross-shard FKs iirc. There's no magic way to shard a relational DB, you have to deal with it one way or another.

benjiro3• 1 year ago

Just beware that CockroachDB is not a drop-in replacement for PostgreSQL.

O, its way worse then that... A ton of small functionality tend to be missing or work differently. Sometimes even small stuff like column[1:2] does not even exist in CRDB and other times its things like ROW LEVEL SECURITY ... you know, something you may want on a mass distributed database then will be use for tenant setups (i hear they are finally going to implement it this year).

The main issue is the performance... You are spending close to ~4x the resources on a similar performing setup. And this is a 2x Pgres (sync) vs 3x CRDB (where every node is just a replica). Its not the replication itself but the massive overhead on the raft protocol + the way less optimized query planner.

To match Pgres, your required to deploy around 10 a 12 nodes, on hardware that needs about twice the resources. That is the point where CRDB performance on a similar level.

The issue is, well, you increase the resources to your Postgresql server and the gap is back. You can scale Postgresql to insane levels with 64, 96 CPUs ... Or imagine, you know, just planning your app in advance in such a way, that you spread your load over multiple Postgresql instances. Rocket science folks ;)

CRDB is really fun to watch, the build in GUI, the replication being very visual, but its a resource hog. The storage system (peble) eats a ton of resources to compact the data, when you can simply solve that with a PostgreSQL instance with zfs (with ironically, often better compression).

I do not joke when i say, that seeing those step cpu spikes in the night hours of the compacter working, is painful. Even a basic empty CRDB instance, just logging its own usage, runs between 7 to 50% on a quad ARM N1, constantly.

PostgreSQL? You do not even know its running. Barely any CPU usage, what memory usage?

And we have not talked license/payment issues ... Of "free enterprise" version with FORCED telemetric on, AND your not allowed to hide the server (aka, if it can not call home, it goes into restricted mode in 7 days, with like 50 queries / second ... aka, the same as just shutting down your DB ). By the way, some people reported that its 125+ dollar/vcore payment. Given that even the most basic CRDB gets you 3x instances, with minimum 4 cores ... Do the math. Yea, after 10M income but they chance their licenses every few years, so who knows next year or the year after that.

Interesting product, shitty sales company behind it. I am more interested to see when the postgresql storage extension orioledb comes out, so it solve the main issue that prevents postgresql scaling even more, namely the write/vacuum issue. And ofcourse a better solution to upgrade postgresql versions, there CRDB is leaps and bound better.

aprdm2• 1 year ago

99.9% of the companies in the world will never need more than 1 beefy box running postgres with a replica for a manual failover and/or reads.

frollogaston5• 1 year ago

Availability is trickier than scalability. An async replica can lose a few recent writes during a failover, and a synchronous replica is safer but slower. A company using some platform might not even know which one they're using until it bites them.

wavemode• 1 year ago

99.9% of companies also aren't going to feel the performance difference of synchronous replication.

That being said, the setups I typically see don't even go that far. Most companies don't mitigate for the database going down in the first place. If the db goes down they just eat the downtime and fix it.

Eikon21• 1 year ago

I run a 100 billion+ rows Postgres database [0], that is around 16TB, it's pretty painless!

There are a few tricks that make it run well (PostgreSQL compiled with a non-standard block size, ZFS, careful VACUUM planning). But nothing too out of the ordinary.

ATM, I insert about 150,000 rows a second, run 40,000 transactions a second, and read 4 million rows a second.

Isn't "Postgres does not scale" a strawman?

[0] https://www.merklemap.com/

rednafi11• 1 year ago

Damn, that’s a chonky database. Have you written anything about the setup? I’d love to know more— is it running on a single machine? How many reader and writer DBs? What does the replication look like? What are the machine specs? Is it self-hosted or on AWS?

By the way, really cool website.

Eikon21• 1 year ago

I'll try to get a blog post out soon!

Damn, that’s a chonky database. Have you written anything about the setup? I’d love to know more— is it running on a single machine? How many reader and writer DBs? What does the replication look like? What are the machine specs? Is it self-hosted or on AWS?

It's self-hosted on bare metal, with standby replication, normal settings, nothing "weird" there.

6 NVMe drives in raidz-1, 1024GB of memory, a 96 core AMD EPYC cpu.

A single database with no partitioning (I avoid PostgreSQL partitioning as it complicates queries and weakens constraint enforcement, and IHMO is not providing much benefits outside of niche use-cases).

By the way, really cool website.

Thank you!

sa46• 1 year ago

I used to run a bunch of Postgres nodes at a similar scale. The most painful parts (by far) were restoring to a new node and major version upgrades.

Any tricks you used for those parts?

Eikon21• 1 year ago

were restoring to a new node

Zfs send / recv or replication.

I used to run a bunch of Postgres nodes at a similar scale. The most painful parts (by far) were restoring to a new node and major version upgrades. Any tricks you used for those parts?

Replication makes this pretty painless :)

marsavar• 1 year ago

That's amazing! Could you elaborate more on your VACUUM planning?

Eikon21• 1 year ago

Mostly, be careful with long-running transactions (hours long), and modify your autovacuum settings to be as aggressive as possible based on your workload. Be careful with the freezing threshold too.

I ran into

    multixact "members" limit exceeded

Quite a bit when starting out :)

nesarkvechnep2• 1 year ago

Because no one else cares to ask, are you running FreeBSD? I ask because you use ZFS.

Eikon21• 1 year ago

Debian!

shayonj3• 1 year ago

I insert about 150,000 rows a second

That's amazing - I would love to know if you have done careful data modeling, indexing, etc that allows you to get to this and what kind of data is being insert ed?

Eikon21• 1 year ago

I am not optimizing too much around insertion speed. I avoid GIN, GIST and hash indexes.

The schema is nicely normalized.

I had troubles with hash indexes requiring hundreds of gigabytes of memory to rebuild.

Postgres B-Trees are painless and (very) fast.

Eg. querying one table by id (redacted):

    EXPLAIN ANALYZE SELECT * FROM table_name WHERE id = [ID_VALUE];

    Index Scan using table_name_pkey on table_name  (cost=0.71..2.93 rows=1 width=32) (actual time=0.042..0.042 rows=0 loops=1)
     Index Cond: (id =  '[ID_VALUE]'::bigint)
    Planning Time: 0.056 ms
    Execution Time: 0.052 ms

Here’s a zpool iostat 1

    # zpool iostat 1
    operations     bandwidth 
     read  write   read  write
    -----  -----  -----  -----
     148K   183K  1.23G  2.43G
     151K   180K  1.25G  2.36G
     151K   177K  1.25G  2.33G
     148K   153K  1.23G  2.13G

dist1ll• 1 year ago

150k rows/second is pretty ordinary if you do batching, especially for a machine of that size. I was able to get 250k+ row inserts on a 16vCPU on a table with 16 columns, a third of which are strings >30 bytes. Pretty sure you can push that much higher with COPY.

kelafoja• 1 year ago

One of things I find challenging is understand the meaning of the word "scales". It is sometimes used differently in different contexts.

Can it be performant in high load situations? Certainly. Can is elastically scale up and down based on demand? As far as I'm aware it cannot.

What I'm most interested in is how operations are handled. For example, if it's deployed in a cloud environment and you need more CPU and/or memory, you have to eat the downtime to scale it up. What if it's deployed to bare metal and it cannot handle the increasing load anymore? How costly (in terms of both time and money) is it to migrate it to bigger hardware?

pluto_modadic• 1 year ago

a database scaling dramatically up and down /under load/ and expecting it to perform the same as steady state seems a bit weird, vs a single, beefy database with a beefy ingest job and a bunch of read only clients searching it?

like you're more likely to encounter two phases (building the DB in heavy growth mode, and using the DB in light growth heavy read mode).

A business that doesn't quite yet know what size the DB needs to be has a frightening RDS bill incoming.

nine_k• 1 year ago

When it "scales", it usually means "scales up". A scalable solution is such that can withstand a large and increasing load, past the usual limitations of obvious solutions.

Being elastic is nice, but not always needed. In most cases of database usage, downsizing never happens, or expected to happen: logically, data are only added, and any packaging and archiving only exists to keep the size manageable.

MR4D• 1 year ago

Having some issues with your numbers, but I’m probably just missing something…

If you insert 150K rows per second, that’s roughly 13 Billion rows per day.

So you’re inserting 10%+ of your database size every day?

That seems weird to me. Are you pruning somewhere? If not, is your database less than a month old? I’m confused.

Eikon21• 1 year ago

Well, that's why I said "ATM", it's not a sustained rate, all the time. And yes, there's a bunch of DELETEs too.

oa335• 1 year ago

Can you please share some tips and tricks for achieving such high throughput?

tnorgaard• 1 year ago

Super interesting compiling pg, I assume, with same as the zfs block size! It was always on our todo to try, but never got around to it. If possible, what block size did you end up with? Have you tried zfs direct io in 2.3.x, if so, could you share any findings? Thanks for sharing - and cool website!

Eikon21• 1 year ago

I don’t think Postgres will be able to benefit from direct io? I might be wrong though!

I use Postgres with 32K BLKSZ.

I am actually using default 128K zfs recordsize, in a mixed workload, I found overall performance nicer than matching at 32K, and compression is way better.

Thanks for sharing - and cool website!

Thank you!

frollogaston5• 1 year ago

"Postgres does not scale" means that you can't just give it more machines, which is true. At some point you've got the fastest available machine, maybe you've played with the settings, and that's it. Then you can embark on the kind of manual sharding journey the article describes.

But most of the time, an RDBMS is the right tool for the job anyway, you just have to deal with it.

Eikon21• 1 year ago

"Postgres does not scale" means that you can't just give it more machines, which is true.

Well, it’s only true for writes.

ambicapter• 1 year ago

ATM, I insert about 150,000 rows a second, run 40,000 transactions a second, and read 4 million rows a second.

Silly question but is this at the same time, regular daily numbers or is that what you've benchmarked?

mmontagna9• 1 year ago

People run postgres at scale which is much "larger" than what you are running, which isn't to say that your workload isn't substantial, it is. But there are folks who push it harder, both in terms of writes/rows and workload complexity. It's one thing to write a ton of rows into a single table, it's another thing entirely to write into many tables, index all of them and then query them at scale; you didn't mention much about your workload complexity so I'm not trying to suggest it isn't complex, but there are certainly plenty of folks on this forum who can attest to it being tricky to scale high write workloads, in large organizations with many stakeholders and complex query loads.

Eikon21• 1 year ago

it's another thing entirely to write into many tables, index all of them and then query them at scale

Well, that’s pretty much what I am doing.

amw-zero• 1 year ago

Curious. At that scale and transaction rate, are you deleting / offloading rows to another storage solution after some amount of time? I’m assuming you’re not just letting 150,000 rows a second accumulate indefinitely.

Shorn• 1 year ago

PostgreSQL compiled with a non-standard block size

Do you think this could become less important for your use case the new PG17 "I/O combining" stuff?

https://medium.com/@hnasr/combining-i-os-in-postgresql-17-39...

Eikon21• 1 year ago

No, because the custom block size is about reducing zfs r/w amplification.

vanviegen2• 1 year ago

Regarding MerkleMap: Ouch! I never realized letsencrypt is leaking all of the sub domains i'm creating. :-/ I thought the names were giving me a bit of extra security through obscurity.

Why does it do that? I thought only revocations need to be published?

jorams• 1 year ago

It does that because it's required to. The system is called Certificate Transparency[1] and browsers require certificates to be in CT logs to be accepted.

If you want to hide what subdomains you have you can use a wildcard certificate, though it can be a bit harder to set up.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Certif...

nickf• 1 year ago

Curious as to why it’s that many inserts? The whole CT ecosystem has about 30-40,000 new certs/precerts a minute IIRC). Love merkelmap though!

Eikon21• 1 year ago

There’s backlog I still need to process :)

chrisandchris2• 1 year ago

And here I am, having an ERP software at hand whose database I "should not query" with some (3-6) joins and likely in the 100'000s of records in total in the larger tables because "the DB server will go down".

WorldWideWebb• 1 year ago

PeopleSoft?

plavreshin• 1 year ago

You have decent documentation portal https://www.merklemap.com/documentation with related articles and API examples, great work! By the way, did you use any markdown2html converter here to built developer portal or this is just a simplified Redocly version of it?

Eikon21• 1 year ago

It’s mdx, with nextjs.

Thanks for the kind words!

kristianpaul• 1 year ago

Logical replication works both ways, thats a good start.

briankelly2• 1 year ago

People talk about scale frequently as a single dimension (and usually volume as it relates to users) but that can be oversimplifying for many kinds of applications. For instance, as you are thinking about non-trivial partitioning schemes (like if there is high coupling between entities of the same kind - as you see in graphs) is when you should consider alternatives like the Bigtable-inspired DBs, since those are (relatively) more batteries included for you.

It’s funny to write this. The Internet contains at least 1 (or maybe 2) meaty blog posts about how this is done

It would’ve been great to link those here. I’m guessing one refers to StackOverflow which has/had one of the more famous examples of scaled Postgres.

levkk12• 1 year ago

I was thinking of the Instagram post years ago. And maybe the Instacart one.

briankelly2• 1 year ago

Maybe this one for Instagram? https://instagram-engineering.com/sharding-ids-at-instagram-...

banashark• 1 year ago

Notion wrote about their experience before:

https://www.notion.com/blog/sharding-postgres-at-notion

https://www.notion.com/blog/the-great-re-shard

octernion• 1 year ago

i was reading through this and was going "huh this sounds familiar" until i read who wrote it :)

neat piece of tech! excited to try it out.

fourseventy• 1 year ago

I run a postgresql db with a few billion rows at about 2TB right now. We don't need sharding yet but when we do I was considering Citus. Does anyone have experience implementing Citus that could comment?

caffeinated_me4• 1 year ago

It can be great, depending on your schema and planned growth. Questions I'd be asking in your shoes:

1. Does the schema have an obvious column to use for distribution? You'll probably want to fit one of the 2 following cases, but these aren't exclusive:

    1a. A use case where most traffic is scoped to a subset of data. (e.g. a multitenant system). This is the easiest use case- just make sure most of your queries contain the column (most likely tenant ID or equivalent), and partially denormalize to have it in tables where it's implicit to make your life easier. Do not use a timestamp. 

    1b. A rollup/analytics based use case that needs heavy parallelism (e.g. a large IoT system where you want to do analytics across a fleet). For this, you're looking for a column that has high cardinality witout too many major hot spots- in the IoT use case mentioned, this would probably be a device ID or similar

2. Are you sure you're going to grow to the scale where you need Citus? Depending on workload, it's not too hard to have a 20TB single-server PG database, and that's more than enough for a lot of companies these days.

3. When do you want to migrate? Logical replication in should work these days (haven't tested myself), but the higher the update rate and larger the database, the more painful this gets. There's not a lot of tools that are very useful for the more difficult scenarios here, but the landscape has changed since I've last had to do this

4. Do you want to run this yourself? Azure does offer a managed service, and Crunchy offers Citus on any cloud, so you have options.

5. If you're running this yourself, how are you managing HA? pg_auto_failover has some Citus support, but can be a bit tricky to get started with.

I did get my Citus cluster over 1 PB at my previous job, and that's not the biggest out out there, so there's definitely room to scale, but the migration can be tricky.

Disclaimer: former Citus employee

eximius2• 1 year ago

Something I don't see in the pgdog documentation is how cross-shard joins work. Okay, if I do a simple `select * from users order by id`, you'll in-memory order the combined results for me. But if I have group by and aggregations and such? Will it resolve that correctly?

levkk12• 1 year ago

Aggregates are a work in progress. We're going to implement them in this order:

1. count

2. max, min, sum

3. avg (needs a query rewrite to include count)

Eventually, we'll do all of these: https://www.postgresql.org/docs/current/functions-aggregate..... If you got a specific use case, reach out and we'll prioritize.

eximius2• 1 year ago

Heh, no chance I can introduce this at work and hard to have a personal project requiring it. :)

I think you probably need some documentation to the effect of the current state of affairs, as well as prescriptions as to how to work around it. _Most_ live workloads, even if the total dataset is huge, have a pretty small working set. So limiting DB operations to simple fetches and doing any complex operations in memory is viable, but should be prescribed as the solution or people will consider it's omission as a fault instead of a choice.

akshayshah• 1 year ago

Apart from being backed by Postgres instead of MySQL, is this different from Vitess (and its commercial vendor PlanetScale)?

https://vitess.io/

levkk12• 1 year ago

The goal for this project is to be analogous to Vitess for Postgres.

Karupan• 1 year ago

Tangentially related: is there a good guide or setup scripts to run self hosted Postgres with backups and secondary standby? Like I just want something I can deploy to a VPS/dedicated box for all my side projects.

If not is supabase the most painless way to get started?

gourneau• 1 year ago

I’m working with several Postgres databases that share identical schemas, and I want to make their data accessible from a single interface.

Currently, I’m using Postgres FDWs to import the tables from those databases. I then create views that UNION ALL the relevant tables, adding a column to indicate the source database for each row.

This works, but I’m wondering if there’s a better way — ideally something that can query multiple databases in parallel and merge the results with a source database column included.

Would tools like pgdog, pgcat, pganimal be a good fit for this? I’m open to suggestions for more efficient approaches.

Thanks!

sourtrident• 1 year ago

Funny how everyone eventually hits this point and thinks they're inventing fire - but then again, pushing your trusty old tools way past comfort is where cool engineering actually happens.

roark_howard• 1 year ago

Shouldn't the title be 'Learning to scale Postgres'?

Nelkins• 1 year ago

How does PgDog handle a column like:

`id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY`

levkk12• 1 year ago

Replace it with a function that makes sure the id coming out matches the sharding schema. Assuming it's coming from a sequence, we're consuming it until we get a matching number. It would be good to know what is behind the generated column in your use case.

moribvndvs• 1 year ago

DynamoDB is most certainly not the way.

Making Postgres scale

Related Stories