17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.
17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.
The costs as a whole has me worried. I'm not sure it'll be better than just using https://turso.tech/pricing as that is already a free tier of 8GB and it might cost less overall the paid tier.
Is it a non-goal to be long term usable for larger databases? That would force the usage of something like turso your closest direct comparison as a possible migration strategy or relying on "Smart Placement" (which from my point of view reduces the benefit of global edge) for other serverless non-global dbs.
Personally, I'm a firm believer that most "web app" use cases are better served by many small databases (e.g. per-user or per-document) rather than a single monolithic databases. This is especially true when serving users all around the world -- per-user databases can be located near each user (both for speed and to comply with data locality laws).
What I'd like to enable here is a progression where you start out prototyping your app with a single D1 database, which is easy to use and reasonably fast. Then as you grow we provide tools to let you transition to many D1 databases sharded in a way that makes sense (e.g. per-user). Apps that want even more control can move to using full-on Durable Objects (which will soon support a SQLite database per-object).
That said, there are certainly many use cases out there where simple monoliths make sense, especially non-interactive data crunching. I'm not sure yet if D1 will ever be the right choice for those, but the Workers platform aims to provide many options.
Thanks for the insight, I greatly appreciate it! This definitely is a reasonable idea for many things and I'm looking forward to seeing something similar to the sharding mechanism in the future.
I've only started to think about this and I'm thinking the hardest part will be dealing with cross-cutting concerns (in a non-auto sharded world manually creating multiple database) and trying to find a way to keep each database isolated without extra burden compared to using a hosted Postgres.
As an aside, that lan optimized house was a gaming dream. Hope your new house is as awesome.
I've been working on a little project that uses D1 and have been hoping that is how D1 will evolve. A db per customer in my case. Is the colocation in a durable object so 'business logic' and sqlite can live in the same isolate for performance and security? Would that be a post 'out of beta' feature? Ive been building as a monolith thinking that the number of databases in the alpha was indicative of the future.
Sorry, I don't quite understand what you're asking.
In the future each DO will have a private SQLite database. The key/value store will actually be redirected to store into a special table in this database, but probably new apps will just use the database and not the KV store.
Separately from that, I would like to develop tools that make sharding Durable Objects (and D1 databases) easier. Today it's a pain to do manually. This is independent from the underlying storage model, though.
I mean, our object storage is called R2, our first database offering is called D1, and if we were to offer a fully Distributed Database then D2 seems like a good name.
This is my first time using it and I've been very pleased with it so far. It keeps it simple, has solid typing & schema building, and reminds me of LINQ. I'm also a thin models kind of person and the fact this is just an object without needing to build ORM classes is even better.
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: 15+ years in engineering with 15+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list (includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.
Resume/CV: JS for my linkedin atob('aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2dyZWctY2FuLXRoaW5rLw==')
Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
I'm currently a Staff Engineer who has and can work the entire stack (architected most of the current frontend I work on, write APIs, can work with databases, have created CI pipelines, etc.), but I've been wanting to become some form of Engineering Manager. I've found mentoring and helping others extremely rewarding and I've been told my passion about technology inspires others. I'd be interested in a purely IC job only at a place that really proves it is worth changing from my current company and job. I'm more interested in either a pure manager position or a "50/50 position (the 50/50 cannot be a paid for one job, doing two jobs 100% & 100%).
Clean room design is about wholesale copying of code. If you copied the APIs and architecture and wrote the code differently there would be nothing wrong as SCOTUS just ruled.
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: 13+ years in JavaScript, Node, React, check resume for full list (includes using TypeScript, .Net, Elm, Ruby, Python, Elixir) with strong interest in FP and other languages like Rust
Remote: Yes (only)
Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it
Technologies: JavaScript, Node, TypeScript, React, Solid, Bun, AWS, CI/CD
Resume/CV: https://akkuma.github.io/resume
Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')
My personal site: https://akkuma.github.io
17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.