3 ms·
I'm a pretty experienced Data Engineer working at one of the bigger data companies around. I read your copy and landing page, here's what I took away: 1) New
by edmundsauto 8y ago
I'm a pretty experienced Data Engineer working at one of the bigger data companies around. I read your copy and landing page, here's what I took away:
1) New database product that's an alpha. My first thought is "will be interesting to follow for 5 years to see if they make it". database choice is possibly the single biggest decision I make in my role; I don't make it lightly.
2) It looks like it's trying to bridge the NoSQL/SQL gap -- more consistent for SQL fans, more flexible for NoSQL fans. (My judgement: "serving 2 masters is not a great signal for me to choose this DB" but I'm a SQL curmudgeon.)
3) GraphQL is really neat out of the box. Some neat features overall.
And, finally, I'm still not really sure what situation could possibly arise that would make me choose this DB, mostly because that choice isn't something I'd select a <5 year old solution for.
I do like that it's based on Postgres (Citus taught me how powerful the "build on pg" model can be). I really like the graphql and schema introspection features. I don't think I would put this on my vendor/technology comparison matrix.
Hope this is helpful, please don't read too much into the negative stuff -- if I were choosing any other technology pillar besides a db, I wouldn't be nearly as strict. It's an uphill climb for your team, but I wish you the best of luck!
- 1st1 8y agoThank you for your insightful comment! I agree, people do choose a database based on its track record, and this is where EdgeDB will have to prove itself. Overall, I think that the decision to build on PostgreSQL is a great competitive advantage over other new databases: we can confidently say that the data will be safe with EdgeDB. And we can actually spend more time improving the ergonomics of the data model and the query language.
- buremba 8y agoSince you actually forked Postgresql, how is it realistic to assume that the data will be safe?
- 1st1 8y agoWe maintain the number of modifications to the minimum, and we don't touch critical paths (there's simply no need for that).
- edmundsauto 8y agoDB marketing is an interesting case. It's easier to market on features that devs want, which is what Mongo did. Your serious users (DE w/ years of experience) are more into the reliability and guarantees, the building of which tends to slow down feature launches. (Or, sometimes, the features developers want conflicts with more "Traditional" db systems). One thing I've rarely seen mentioned, but I believe is a force behind MySQL's success: metadata manipulation. DESCRIBE TABLE, SHOW CREATE TABLE,... stuff ends up being a lot more useful than I would think as an outsider. Going from MySQL to pgsql was a steep learning curve because the commands to display table listings (\dt; i think) felt very arcane. Also, being able to rename, add, remove columns. Finally, can I create a table with the same schema (data optional) as another table? I do that a lot.
- StreamBright 8y agoSame here, only thing to add that my number of years before I can consider a database production ready is closer to 10 years. I am willing to make an exception only if a major company with scale and engineering resources uses it and willing to publicly talk about it. RocksDB falls into this category, for example.
- ThinkBeat 8y agoVery well said. I don't want to touch a database product until it has a proven production use for several years. Creating a database is hard, very hard, as history has shown us recently. That it sits on top of Postgres is a great start though.
- whazor 8y agoThe following areas are pretty though when building a new database: - transactions - proper paging - indexes - query engine - and more ... However, if they use postgresql as a base.. it significantly improves the stability and feature completeness. Especially if it is only a different frontend (query language and schema).