Replies: 1 comment 1 reply
-
While we are focusing on Postgres the storage design is general enough and can be adapted to any database system that stores data in pages. So sqlite, mysql, duckdb who all use page based storage subsystem can in theory use Neon storage. However adapting it to those systems is a non trivial amount of systems work and currently off strategy for the company for the time being. I'm in conversations with multiple parties who are considering using Neon storage for those systems. The code is open, we will be thrilled for the community to adapt Neon storage to other systems. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi! I like neon's architecture design of splitting up storage work into pageserver and wal server components.
From afar it appears that the conceptual design of these components are somewhat general, which makes me curious if they could be used as a storage backend for other engines like MySQL or SQLite (or even as a backing store for ZFS?). I recall reading that the pageserver actually reconstructs valid postgresql pages on demand and the actual backing storage has a different format, so this may be more complex than pointing SQLite with a VFS adapter at the existing pageserver and calling it done.
From both an engineering-possibility perspective as well as project-priority perspective, what do you think about using neon's backing storage architecture for other database engines?
Beta Was this translation helpful? Give feedback.
All reactions