[sa-code]

Qdrant is also a good default choice, since it can work in-memory for development, with a hard drive for small deployments and also for "web scale" workloads.

As a principal eng, side-stepping a migration and having a good local dev experience is too good of a deal to pass up.

That being said, turbopuffer looks interesting. I will check it out. Hopefully their local dev experience is good

[nostrebored]

Qdrant is one of the few vendors I actively steer people away from. Look at the GitHub issues, look at what their CEO says, look at their fake “advancements” that they pay for publicity on…

The number of people I know who’ve had unrecoverable shard failures on Qdrant is too high to take it seriously.

[sa-code]

I’m curious about this. Could you please point to some things the CEO has said, or reports of shard failures?

The bit about paying for publicity doesn’t bother me.

Edit: I haven’t found anything egregious that the CEO has said, or anything really sketchy. The shard failure warnings look serious, but the issues look closed

https://github.com/qdrant/qdrant/issues/6025

https://github.com/qdrant/qdrant/issues/4939

[andre-z]

What do I say? Happy to talk about "fakes". Here is my calendar. Feel free to book a slot. https://qdrant.to/andre-z

[benesch]

For local dev + testing, we recommend just hitting the production turbopuffer service directly, but with a separate test org/API key: https://turbopuffer.com/docs/testing

Works well for the vast majority of our customers (although we get the very occasional complaint about wanting a dev environment that works offline). The dataset sizes for local dev are usually so small that the cost rounds to free.

[lambda]

> although we get the very occasional complaint about wanting a dev environment that works offline

It's only occasional because the people who care about dev environments that work offline are most likely to just skip you and move on.

For actual developer experience, as well as a number of use cases like customers with security and privacy concerns, being able to host locally is essential.

Fair enough if you don't care about those segments of the market, but don't confuse a small number of people asking about it with a small number of people wanting it.

[sroussey]

That’s not local though

[enigmo]

having a local simulator (DynamoDB, Spanner, others) helps me a lot for offline/local development and CI. when a vendor doesn't off this I have often end up mocking it out (one way or another) and have to wait for integration or e2e tests for feedback that could have been pushed further to the left.

in many CI environments unit tests don't have network access, it's not purely a price consideration.

(not a turbopuffer customer but I have been looking at it)

[sa-code]

I should have clarified, by local dev and testing I did in fact mean offline usage.

Without that it’s unfortunately a non starter