Hi! Hammad here - Chroma’s CTO. First off, I have an immense amount of respect for the Turbopuffer team, they’ve build a solid product.
I understand your point. Chroma Cloud has been quietly live in production for a year, and we have been discussing this architecture publicly for almost two years now. You can see this talk I gave at the CMU databases group - https://youtu.be/E4ot5d79jdA?si=i64ouoyFMevEgm3U. Some details have changed since then. But the core ideas remain the same.
The business model similarities mostly fall out of our architecture being similar, which mostly falls out of our constraints with respect to the workload being the same. There are only so many ways you can deliver a usage based billing model that is fair, understandable, and predictable. We aimed for a billing model that was all three, and this is what we arrived at.
On aesthetics, that’s always been our aesthetic, I think a lot of developer tools are leaning into the nostalgia of the early PC boom during this AI boom (fun fact, all the icons on our homepage are done by hand!).
On differences, we support optimized regexes vs full-scans, lending better performance. We also support trigram based full-text search which can often be useful for scenarios which need substring matches. We also support forking, which allows for cheap copy-on-write clones of your data, great for dataset versioning and tracking git repos with minimal cost. We've been building with support for generic sparse vectors (in beta) which enables techniques like SPLADE to be used, rather than just BM25. You can also run Chroma locally, enabling low-latency local workflows. This is great for AI apps where you need to iterate on a dataset until it passes evals, and then push it up to the cloud.
Chroma is Apache 2.0 open source - https://github.com/chroma-core/chroma and has a massive developer community behind it. Customers can run embedded, single-node and distributed Chroma themselves. We've suffered from depending on closed-source database startups and wanted to give developers using Chroma confidence in the longevity of their choice.
Lastly, we are building with AI workloads front and center and this changes what you build, how you build it and who you build for in the long term. We think search is changing and that the primary consumer of the search API for AI applications is shifting from human engineers, to language models. We are building some exciting things in this direction, more on that soon.
That is definitely one of the biggest painpoints, and we feel it ourselves for whatever it's worth!
However, if you're just looking for a replacement for Pocket, you only need the Reader app/extension and it shouldn't be clunky at all.
It's only if you want our highlight-specific reviewing/exporting functionality that you would also need the Readwise app... still not ideal, but merging two complex products like this without making the experience janky/complicated for new users is a really really hard problem!
The current pricing of Readwise seems like it will not be attractive to the 99% of Pocket users who are just looking for a reader app, and don't want to plunk down $120 every year for that (and various other features they aren't looking for).
It looks like you have a "Lite" tier that doesn't include the reader app. Maybe there should be a free tier that offers only the reader app, and you can try to upsell users from there. Otherwise people who just want a reader app will migrate to Instapaper or other free reader apps. I know that's what I plan on doing!
A lite tier that's only the Reader app would be great. I'm exploring self hosted options to replace Readwise Reader due to the price being a little hard to justify and not using most of the features except the website saving.
BookFusion (cross platform ePub reading app) by comparison has a great pricing structure that makes it hard to ever consider unsubscribing for the value I get. Highly recommend the app for anyone who uses Android eReaders in combo with iOS devices/desktop.
Even when I was a new user right as Reader was getting started, I didn't think it was clunky to be honest. I thought it was clear when I was using one vs. the other. The only problem I've ever had is that typing/saying "Readwise Reader" is a bit clunky when discussing the product, but "Readwise" refers to the other one, and "Reader" isn't a sufficient name itself.
You can connect Pocket to Readwise Reader ( readwise.io/reader ), via Pocket's API, which will let Reader view all the tags, metadata, highlights, etc.
Even if you didn't want to use Reader, you could then export from inside Reader and Readwise to pull out CSVs of all of your articles+highlights -- no subscription required.
(full disclosure: founder of Readwise here, obviously if you want to try our Reader app that would be sweet, but at least wanted to offer this way to get a more complete export)
No, unfortunately their API doesn't return the actual html content of the saved articles :( just the urls and all the metadata: highlights, title, author, image, tags, location, etc
I really wish they did :/ some things aren't even on the internet archive and are probably saved uniquely on Pocket's servers. Would be sweet if they could open source that data.
Love your app. Any plans to enable reading of Readwise Reader articles on eReaders like Kobo? I’m thinking of something akin to how Pocket’s integration with Kobo.
Thanks! Kobo is hard because it's proprietary software, but we would like to...
However, there is a wide range of eink devices that already exist that run Android (check out Boox, Meebook, Daylight, though there are many others) -- we've optimized Reader to run great on these devices :)
It would be really amazing if you could attempt for those who've connected Pocket to pull the data of all those saved files etc into Reader. I realize it wouldn't necessarily work as some stuff is just gone, but it would be a nice feature for those of us moving over.
Cool! The import should auto-retry, but in case something gets snagged there you can also always do `cmd+k -> pocket` to retrigger a full import.
Totally hear you on price.. Reader is built for people who spend a lot of time reading and can justify it (and the sub also comes with access to our Readwise product too).
We also have a 50% off discount for students as well folks in countries with depressed currencies (eg India, South American countries, etc) which might help.
We try our best, but are also bootstrapped and have to charge enough to keep the company sustainable!
seems to work better with https://fabiensanglard.net/rss.xml than most readers although it still gets 403s fetching images but I'll still give it a run to see how it works for me.
This is basically our exact experience at readwise.io too. Originally, everything was through Heroku.
We started by moving our heroku redis and postgres to redislabs and crunchy respectively, which were 10x+ better in terms of support, reliability, performance, etc. Then our random addons.
We recently moved our background job workers (which were a majority of our Heroku hosting cost) to render.com with ~0 downtime. Render has been great.
We now just have our web servers running on Heroku (which we'll probably move to Render next year too)...
End of an era. Grateful for Heroku and the next generation of startups spawned by its slow decline :)
Honestly just loading all vectors in-memory (and stuff like sqlite, pgvector) is totally fine when you're dealing with O(100k) vectors, but beyond that all the workable options like pinecone get gnarly, slow, and ridiculously expensive.
The best option by far I know of is turbopuffer.com , which is like 100x cheaper than pinecone and seems to actually scale.
Since it's not listed in the suggested vector dbs section of the slides, wanted to lob it in as a solid suggestion :)
Sort of off topic, but for diagrams like the author seems to want (well, maybe a little lower fidelity, but good enough for any software system mapping I do), I love using Kinopio (kinopio.club)
Does anyone have a good idea of when OPFS will be broadly available in all major browsers? And what's best to use as a pseudo-polyfill in the mean time?
Something relevant is absurd-sql, but unfortunately that's not even close to production ready :/
Hey! Totally understand this concern with the browser extension. I mentioned this in another comment, but there was no way to build the full functionality without these permissions, though we do hope to make a lighter version of the extension in the future for more privacy-conscious folks.
However, completely understand the request, and we do value privacy/security super highly. All extension data stays local on your device unless you actively press the extension button to save a page/content. You'd have to read our source code and network requests to confirm this right now, of course.
Another commenter also mentioned, we do indeed have a super light bookmarklet that can serve this purpose in the mean time as well
Down to the style of the webpages and the details of the pricing?
Here's the pricing calculator, for example:
https://share.cleanshot.com/JddPvNj3 https://share.cleanshot.com/9zqx5ypp
As a happy turbopuffer user, not sure why I'd want to use Chroma.