Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ArangoDB 3.7 – a big step forward for multi-model

arangodb.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: ArangoDB 3.7 – a big step forward for multi-model

#11

Post by rishav_sharan »

Arangodb has always been the db that I always keep checking back every few months. I love the idea and using it has been a peach so far. This is a very underrated db and I wish more people can get into it.

To me, its best bits are;

1. AQL - I absolutely adore AQL- the query language that you use in Arangodb. I haven't seen anything like it so far and it was somethingI could pick up in 5 mins.

2. Multi-modal - love the idea of being able to use the same db for graph and object based data. With the new search and other geo features, this bit has become even more tempting.

3. Orchestration - ability to have self healing clusters of db nodes makes the overall backend super redundant and safe. and also helps with latency by enabling me to have a node in each region that I want to optimize for.

Despite all this, I almost always end up going for Postgres for my personal projects.

Coming to the negatives, for me the biggest missed opportunities are;

1. Not providing a free tier for the managed service. I really would want to use the service for small toy projects without worrying about a time limit. All of the managed service providers have a free/community tier and without it, I don't see their service succeeding.

2. Foxx server-in-db This one pains me so much. I feel Foxx is the killer feature thay have that can push them past Postgres. Having the web server and the db in the same node makes architecting the backend so simple. But Foxx really isn't designed with developer ergonomics in mind. Issues that i opened years ago are still open, without any major update which would make developing in Foxx less than a chore. I would drop other web frameworks+dbs in a heartbeat, if Foxx was easy to develop in.

3. No Jepsen report. No techempower entry for a Foxx+arangodb backend. No realworld backend app using arangodb. No major independent benchmarks.

Re: ArangoDB 3.7 – a big step forward for multi-model

#12

Post by brian_cloutier »

maxpert wrote: post #7

Would somebody say it can hold data as reliably as postgres. I’ve been very very impressed recently with Postgres and how long a DB can go (using Aurora right now). I would love to try it out but I am just too iffy on if it will withstand the load reliably (even in events of a crash).

I wish databases were more modular, I would love to be able to experiment with other models for what a database could be, backed by the rock-solid postgres write ahead log.

Re: ArangoDB 3.7 – a big step forward for multi-model

#13

Post by dotBen »

FpUser wrote: post #4

I guess it is just me but as soon as I see "contact our sales" instead of price I turn away. Absence of perpetual license instead of monthly fee does not help either.

Running a database business is especially hard - constant development is needed and so one time perpetual licenses don't really reflect the on-going costs (esp staff) that a database company has.

Mix in the risk that your high value users end up using the FOSS edition and it can get especially difficult.

Re: ArangoDB 3.7 – a big step forward for multi-model

#15

Post by didibus »

Those features are interesting, but how much can it scale? What performance (read and write) can I expect? How easy is it to update a schema? How does it handle pagination or queries with really large result sets? What's the limits on the size of data I can store in it (total, per field, per row, etc.) And how does it handle security? Is everything encrypted at rest and in transit? Can the index work over encrypted fields? Etc.

Re: ArangoDB 3.7 – a big step forward for multi-model

#16

Post by rikroots »

rishav_sharan wrote: post #11

Arangodb has always been the db that I always keep checking back every few months. I love the idea and using it has been a peach so far. This is a very underrated db and I wish more people can get into it. To me, its best bits are; 1. AQL - I absolutely adore AQL- the query language that you use in Arangodb. I haven't seen anything like it so far and it was somethingI could pick up in 5 mins. 2. Multi-modal - love th…

I agree with the above points (except Foxx - that looked too scary, so I pretended it didn't exist so I have no opinion on how good/useful it could be). Getting the database up-and-running on my local machine was pretty painless and AQL was a joy to use.

The thing that put me off using it for anything other than a local toy project was the costs (at the time) of hosting the database anywhere outside of my laptop. Deploying ArangoDB in a Docker container on AWS ECS was far too much money to justify for any of my side projects. Hopefully running costs are a lot cheaper nowadays?

Re: ArangoDB 3.7 – a big step forward for multi-model

#17

Post by nqzero »

rishav_sharan wrote: post #11

Arangodb has always been the db that I always keep checking back every few months. I love the idea and using it has been a peach so far. This is a very underrated db and I wish more people can get into it. To me, its best bits are; 1. AQL - I absolutely adore AQL- the query language that you use in Arangodb. I haven't seen anything like it so far and it was somethingI could pick up in 5 mins. 2. Multi-modal - love th…

techempower has been very resistant to alternative databases. i pursued the effort for a couple years and gave up (so possible that it's improved in the last 12-18 months). their business is based on enterprise consulting - i suspect it's clouding [sic] their view of frameworks

Re: ArangoDB 3.7 – a big step forward for multi-model

#18

Post by kyriakos »

didibus wrote: post #15

Those features are interesting, but how much can it scale? What performance (read and write) can I expect? How easy is it to update a schema? How does it handle pagination or queries with really large result sets? What's the limits on the size of data I can store in it (total, per field, per row, etc.) And how does it handle security? Is everything encrypted at rest and in transit? Can the index work over encrypted f…

Great points here. I hear a lot of about a lot of DB's especially the new kids on the block but unless I see how they behave once you got a few TB of data in them I cannot even contemplate using them in production. Things like schema changes, backup/restore, latency, fault tolerance etc are very important to leave to chance and believe the initial marketing.

Re: ArangoDB 3.7 – a big step forward for multi-model

#19

Post by nqzero »

FpUser wrote: post #4

I guess it is just me but as soon as I see "contact our sales" instead of price I turn away. Absence of perpetual license instead of monthly fee does not help either.

would a free (or low cost) tier on a limited number of nodes be something you'd consider for a database product ?

Re: ArangoDB 3.7 – a big step forward for multi-model

#20

Post by drdaeman »

PaulHoule wrote: post #3
mroche wrote: post #2

I’ve been meaning to look Arango for some side projects to learn some NoSQL. Having the primary NoSQL types in one db makes that a bit easier when writing the code, though OrientDB can fit that bill as well. From my limited experience their AQL syntax is pretty good and easy to grok, and the documentation is also good for diving in and understanding the models/features. The concept of Foxx API’s someone can quickly s…

I use adb for online applications (my home control system; it archives sensor readings, keeps configuration data) and also research projects such as loading the MeSH biomedical ontology, following blood vessels from heart to hand, etc. Arangodb = Mongodb - hype + results Don't let your bad experiences with overhyped database scare you away from arangodb. It is real German engineering not US startup culture that start…

> Don't let your bad experiences with overhyped database

I've picked up RethinkDB once. That was early 2016, it had existed for a while (about 6 years at that time), was deemed a stable production-ready database, had passed Jepsen tests without any serious issues, etc etc. Was it overhyped? Could be but I don't think so - it wasn't shoved down anyone's throat, there weren't any "web scale" memes about it, just a post here on HN, every couple months or so, whenever they made some improvements or posted great technical articles. Looked totally good to me.

It was great for development. Yet, it ended up as a small disaster when the production systems gained some traction. Awful disk usage (I've had to read the source to investigate the serialization formats and be aware about undocumented efficiency considerations), led to servers grinding to a halt due to heavy I/O. And when nodes had sustained the load, they had slowly leaked memory (that was not the caches, unless cache size limiters were broken), so eventually kernel had to invoke OOM killer and that caused a node restart. This resulted in a daily/bi-daily 1-minute downtime blips on the health monitoring. Essentially, it was a huge waste of resources for a couple of nice-to-have features. And in the meanwhile, the company who made the database had shut down - after 7 years of existence.

I've gradually replaced almost all of it with CockroachDB which took a fraction of disk space and CPU time. I went for a distributed DB because I had three nodes anyway; and I was feeling adventurous enough to try CockroachDB only because of the idea that I can trivially switch to tried & trusted PostgreSQL at any moment. Fortunately, it seems to work well for my current load and dataset, although that could be just me being lucky.

Now, I believe, unless something is a toy project or one accepts the risk to rewrite things to use a different storage, a database (and other core technologies) should be chosen in a conservative fashion. Unless there is a plan B.

I have a plan for a small new toy project which could possibly benefit from a graph+document database. I've looked at ArrangoDB recently and it could be a good fit. Yet, if ArrangoDB would start to disappoint for me, say, after a few months in production, there will be no plan B - unless I spend more resources designing this escape hatch than I'd save by using a fancy graph database. So I'm picking PostgreSQL - something that may require a bit of extra work but that I'm 100% sure about.

Just an opinion: long-term safety beats development convenience.

Post reply on HN