Stream: interviews

Topic: 651: Bringing Vitess to Postgres

Logbot (Jul 23 2025 at 23:55):

Sugu Sougoumarane, creator of Vitess, comes off sabbatical to bring Vitess to Postgres. We discuss what motivated Sugu to come off sabbatical, why now is the time, the technical challenges of doing so, the implementation details of Multigres (Vitess for Postgres). We also discuss the state of Postgres at scale. :link: https://changelog.fm/651

Tim Uckun (Jul 30 2025 at 23:42):

This was such a great episode. I was left in awe of what Sugu accomplished and also that Google gave him three months of thinking time on a project.

Best of luck to the team.

BTW no mention of cockroach db.

Don MacKinnon (Jul 31 2025 at 16:45):

Loved this episode as well. Had no idea YouTube was using MySql at that scale.

Adam Stacoviak (Aug 02 2025 at 14:28):

I’m pretty sure I mentioned Cockroach but I think it was brief and closer to the end.

Matthew Sanabria (Aug 03 2025 at 14:15):

CockroachDB is great but almost no developer chooses it for a new project due to lack of awareness of it. Everyone thinks PostgreSQL or MySQL and their respective clustering programs.

Tim Uckun (Aug 03 2025 at 21:52):

There is also yugabyte which you never heard about even though it's been around a long time.

Perhaps possible guests for the podcasts.

Matthew Sanabria (Aug 03 2025 at 23:47):

Yeah Yugabyte too. TiDB too.

Ron Waldon-Howe (Aug 04 2025 at 00:51):

i was extremely interested in CockroachDB until they changed the licence

and i understand why teams/companies do it, but it pretty much kills the project instantly for me

Matthew Sanabria (Aug 04 2025 at 17:17):

Tell me about it. One of the reasons I left there.

Andrew O'Brien (Aug 04 2025 at 21:54):

Jerod's "now do SQLite" comment reminded me of the production grade, multi-reader/writer, snapshot and serializable homegrown RDBMS with a SQLite query interface and automatic time sharding that Bloomberg has been quietly building for 20 years (8 years since open sourcing): https://github.com/bloomberg/comdb2

It's not Vitess for SQLite (the commonalities with SQLite don't go much further than the query interface). Also, I don't know of anyone else who's adopted it, let alone any support offerings. And Bloomberg owns the roadmap and will do what they want with it.

But still, I feel like it's an interesting piece of database tech that's rarely discussed. If it had come out of a startup that had IPO'd with a bunch of engineers flush with seed funding, I expect it would've spawned at least one commercial company.

Alex Sims (Aug 05 2025 at 14:36):

Very cool, thanks for sharing. I need to listen to this episode as we’re currently looking at how we can improve write latency from our other fulfilment centres. We can’t shard all of our data due to data residency constraints. I’ve been looking at implementing something like Turso to act as a stateful write through cache with a service that synchronises back to our London DB, but no matter how I’m trying to slice this pie it’s very complex. Vitess was also on my radar, however we use MariaDB so I’m not entirely sure on compatibility, though I’ve seen MariaDB has GalleraCluster mode which looks similar.

Also toying with the idea of seeing how much latency we can save just by leveraging AWS backbone, but the speed of light will only get you so far!

Tim Uckun (Aug 05 2025 at 22:06):

Combdb2 sounds interesting and still being actively developed. It's amazing I have never even heard of it.

There are several projects that give you distributed sqlite.

https://github.com/rqlite/rqlite
https://fly.io/docs/litefs/
https://canonical.com/dqlite
https://turso.tech/

I don't know how they all deal with sharding though. Turso does allow you to create as many databases as you want but of course you need to manage them in the app.

Big sigh from me is that none of them support ruby as an official supported language.

Dustin (Aug 06 2025 at 07:43):

@Tim Uckun aren’t most of them SQLite extensions? How would you need support for a specific language?

Ron Waldon-Howe (Aug 06 2025 at 08:46):

I suppose it depends on if they depart from the file format that is compatible with existing libsqlite and/or per-language bindings

Ron Waldon-Howe (Aug 06 2025 at 08:47):

E.g. I think turso will read SQLite files, but writes a new format to support the new features it adds on top
So, for e.g. Ruby, you'd need Ruby bindings to libturso or something

Tim Uckun (Aug 06 2025 at 21:26):

rqlite and dqlite are daemons that sit in front of sqlite to manage the cluster, I am not sure exactly how litefs works. Turso has their own libsql which is sqlite compatible. They have a ruby wrapper but it didn't work with rails when I tried it even though it worked with a plain old ruby script.

Turso is also rewriting sqlite from scratch but they are not done with that effort yet.

Andrew O'Brien (Aug 07 2025 at 01:38):

If I understand correctly, LiteFS is transparent to the SQLite library in your application. It thinks it’s writing to a file as usual, but the replication is happening in the FUSE filesystem, which captures the write ahead log for replication before passing it along to the normal file system to actually write the changes. https://fly.io/docs/litefs/how-it-works/

Tim Uckun (Aug 07 2025 at 04:38):

Sounds kind of like DRBD.

Anyway this is what they say on the first page

Important: We are not able to provide support or guidance for this product. Use with caution.

Last updated: Aug 18 2025 at 01:38 UTC