Tried DOOM in that page, it's really slow...
The ram is a blob on the db, ofc it's slow
We're Building Postgres in Rust. Using the LLVM of Databases
21–29 of 29 posts
Re: We're Building Postgres in Rust. Using the LLVM of Databases
#22Re: We're Building Postgres in Rust. Using the LLVM of Databases
#23Re: We're Building Postgres in Rust. Using the LLVM of Databases
#24I'm already quite excited about Turso being SQLite-compatible, but adding many features on top. And when a feature is not directly compatible with SQLite (ie: you can't directly read the file with `sqlite3`, it's straightforward to convert). This is great because you know you'll always be able to continue working with that database. Even if Turso stopped working, it's still a valid SQLite database. A combination I wo…
Supporting Postgres is a good goal but honestly the real challenge is extensions. Would supporting Postgres wire compatibility guarantee any Postgres extension would also work? This is one of the problems with Aurora - it’s all well and good until you need an extension that isn’t on the blessed list
There’s a section about extensions in the FAQ.
Re: We're Building Postgres in Rust. Using the LLVM of Databases
#25Earlier quoted context omitted.
> Would supporting Postgres wire compatibility guarantee any Postgres extension would also work? It would not, for obvious reasons.
Care to elaborate? The reasons are not obvious
Wire protocol applies to external interaction with the db.
Internal ABI/API is used by extensions to directly interact with core subsystems and depends on internal models for things like storage.
It might be analogous to HTTP versus an nginx plugin.
Re: We're Building Postgres in Rust. Using the LLVM of Databases
#26> If you have ever babysat a REFRESH MATERIALIZED VIEW cron job, or faked live views with a pile of triggers, read that sentence again: our views update themselves, live. This is the feature Postgres users have quietly wanted for twenty years.
Real-time materialized views - so far mostly Chinese tech shops have solved this - look at Apache Doris, StarRocks - but these are built on top of MySQL then maybe RisingWave which is Postgres wire compatible.
having real-time materialized views means you can take out 1 or 2 infra pieces from your stack e.g Flink & Kafka - for some simplified use cases. that means no more ETL jobs for some use cases.
Re: We're Building Postgres in Rust. Using the LLVM of Databases
#27Earlier quoted context omitted.
Care to elaborate? The reasons are not obvious
Wire protocol applies to external interaction with the db. Internal ABI/API is used by extensions to directly interact with core subsystems and depends on internal models for things like storage. It might be analogous to HTTP versus an nginx plugin.
curious how hard it is to implement wire protocol compatibility vs the internal api surface. Are we talking like, an order of magnitude more work here? I wonder if, for example, Aurora team are literally maintaining forks of extensions for their implementation and that's why only a subset of all possible extensions are supported?
Re: We're Building Postgres in Rust. Using the LLVM of Databases
#28The llvm of databases is not turso, it's datafusion.
datafusion is llvmm for etl engines, they don't have indexes or transactions for example.
Re: We're Building Postgres in Rust. Using the LLVM of Databases
#29[flagged]