cevian

(co-author here) We automatically retry on failures in a while. We also log error messages in the worker (self-hosted) and have clear indicators in the cloud UI that something went wrong (with plans to add email alerts later).

The error handling is actually the hard part here. We don't believe that failing on inserts due to the endpoint being down is the right thing because that just moves the retry/error-handling logic upstream -- now you need to roll your own queuing system, backoffs etc.

(Post co author) We absolutely agree that chunking is critical for good RAG. What I think you missed in our post is that the vectorizer allows you to configure a chunking strategy of your choice. So you store the full doc but then the system well chunk and embed it for you. We don’t blindly embed the full document.

(post co-author here)

It could do either depending on on what the planner decides. In pgvector it usually does post-filtering in practice (filter after vector search).

pgvector HNSW has the problem that there is a cutoff of retrieving some constant C results and if none of them match the filter than it won't find results. I believe newer version of pgvector address that. Also pgvectorscale's StreamingDiskANN[1] doesn't have that problem to begin with.

[1] https://www.timescale.com/blog/how-we-made-postgresql-as-fas...

as far as I can tell Chroma can only store chunks, not the original documents. This is from your docs `If the documents are too large to embed using the chosen embedding function, an exception will be raised`.

In addition it seems that embeddings happen at ingest time. So, if, for example, the OpenAI endpoint is down the insert will fail. That, in turn means your users need to use a retry mechanism and a queuing system. All the complexity we describe in our blog.

Obviously, I am not an expert in Chroma. So apologies in advance if I got anything wrong. Just trying to get to the heart of the differences between the two systems.

haha. We had a good internal debate as to whether this is more like indexes or more like Materialized Views. It's kinda a mixture of the two.

(post co-author here)

The DB is the right layer from a interface point of view -- because that's where the data properties should be defined. We also use the DB for bookkeeping what needs to be done because we can leverage transactions and triggers to make sure we never miss any data. From an implementation point of view, the actual embedding does happen outside the database in a python worker or cloud functions.

Merging the embeddings and the original data into a single view allows the full feature set of SQL rather than being constrained by a REST API.

(post co-author here)

We agree a lot of stuff still needs to be figured out. Which is why we made vectorizer very configurable. You can configure chunking strategies, formatting (which is a way to add context back into chunks). You can mix semantic and lexical search on the results. That handles your 1,2,3. Versioning can mean a different version of the data (in which case the versioning info lives with the source data) OR a different embedding config, which we also support[1].

Admittedly, right now we have predefined chunking strategies. But we plan to add custom-code options very soon.

Our broader point is that the things you highlight above are the right things to worry about, not the data workflow ops and babysitting your lambda jobs. That's what we want to handle for you.

[1] https://www.timescale.com/blog/which-rag-chunking-and-format...

Please note that TimescaleDB also uses columnar storage for its compressed data.

Disclosure: I am a TimescaleDB engineer.

Hah! This was actually one of the main algorithmic challenges of adapting DiskANN to PostgreSQL. Yes, I think it's common for these algorithms to assume you know how many results to return ahead of time. But in PostgreSQL that's not how things work -- because of things like post-index-retrieval-filtering the right interface for Postgres is one that just keeps on returning more and more results until all possible matches are exhausted. We solved this by creating a "streaming" version of the search algorithm that keep state like which nodes in the graph have been visited, which have been returned etc.

That's all to say -- Yes we've solved this, there are no arbitrary limits on the number of results returned.

This article doesn't account for the fact that the role of government funding in science is to fund basic science that industry doesn't have the right incentives to fund. Renewables and energy efficiency do just fine with industry-sponsored R&D. Fusion would not.

Lead engineer here, happy to answer any questions

Timescale [ Worldwide | Fully Remote | Multiple Roles: Eng, Product + more | https://www.timescale.com/

Timescale is continuing to grow rapidly, and we’re hiring for many roles involving distributed systems and databases.

Folks might know TimescaleDB as “Postgres + time-series”: we’re implemented as an extension to PostgreSQL (not a fork), but focus on the scale, performance, and ease-of-use needed for time-series applications. Automated time/space partitioning, columnar compression, continuous aggregates (incrementally materialized views), time-series analytics, and now a distributed database with horizontal scale-out.

Database code all available on github; we don’t have any “enterprise versions”, so all our database code is available for the community for free. Currently see more than 3 million databases running TimescaleDB a month.

That’s because our commercial focus is on our fully-managed cloud platform, so in addition to folks implementing the core database (C, Rust), we’re also heavily hiring for folks with operational cloud & database experience at scale (Kubernetes with custom k8s operators, Golang, etc), as well as folks interested in providing highly technical support, database release engineering, and building database testing infrastructure (think performance analysis, distributed database correctness testing, etc.) And product folks to support these efforts & all our users!

We are also developing Promscale, which makes storing, analyzing, and managing observability (Prometheus metrics & Open-Telemetry traces now, other signals in development) data easier and allows users to use SQL on that data.

Lots of fun engineering and product roles/work, and an amazing company culture you can read more about here: https://www.timescale.com/careers

Feel free to drop me a DM here with any questions (I’m one of the original engineers at Timescale — and now lead the Promscale team), or apply here at https://www.timescale.com/careers

Just one more note. Timescale is hiring, including for roles working on Promscale.

https://www.timescale.com/careers

Promscale roles are listed in the "Observability" section.

(NB: Post author and Promscale dev here)

Promscale does both data storage and analysis/rollups. It's like Thanos in that you can use it as a remote storage backend. It has the additional functionality of then aggregating/analyzing the data in SQL.

(NB: post author here)

Great question. We support average of averages by storing the intermediate state of the aggregate (for average that's the sum and count) so we could cleanly re-aggregate.

Eventually, we'll be able to incrementally update the aggregate if we backfill even if the raw data is no longer available. That's not implemented yet though, so backfill only updates the aggregate if the raw data is still around by re-computing the intermediate state of the aggregate off the raw data for affected buckets. For most cases that isn't actually an issue since most people have a longer data retention period than backfill horizon.

(Timescale engineer here). We believe so and we have customers using us for just that. We haven't created our own product for that yet (as we have for metrics -- Promscale) but it is an idea we are playing with. You may want to look at our Promscale design doc[1] for ideas on table layout.

[1] https://tsdb.co/prom-design-doc

That may indeed have been more accurate. But this is a HN comment thread after all, we can't capture all subtleties of a very complex debate. :)

That's fair but I was more replying to the OP that said "but it shouldn't be called an Open Source license". The point is we don't call our license Open Source.

Comparisons to Open Source and discussions of the pros and cons of both approaches are, of course, fair.

That only makes sense if you agree with the open source foundation definition of restrictive. I don't. I think the ability to freely link to whatever other software is much more important to most people than the ability to run a *aaS. We never made any claims about open source only our opinion about what restrictive means to us.

And we never call it Open Source!

(Timescale engineer here)

(Promscale Team Lead Here) Promscale, which connects Prometheus to TimescaleDB also handles high-cardinality well and allows you to use both PromQL and SQL for data analysis. I'd humbly suggest taking a look. Plus our PromQL implementation is 100% standards compliant.

By the way, for those interested, our first community meeting is Next Wed Oct 14 @ 16:00 UTC / 12:00 EDT

More info: https://tsdb.co/promscale-agenda

(TimescaleDB engineer here) Some of the comments here sound technically off.

We've never seen a backup take down a machine. The backups we use are the same as Postgres which are used by millions of companies without a problem (and can be streaming incremental backups like pgBackrest, WAL-E, etc. or whole-database backups like pg_dump). As with any DB you do have to size and configure your database correctly (which these days isn't hard).

We've never seen anybody claim that ClickHouse offers significantly better compression than we do overall. Obviously compression depends heavily on data distribution and I'm sure you could make up a dataset where clickhouse does better (just as you could where TimescaleDB does better). But on real distributions we don't see this at all, we do pretty advanced columnar compression on a per-datatype basis [1], and see median space reduction of 95% from compression across users.

Large queries is a weird claim to make since Postgres has more different types of indexes than Clickhouse and has support for multiple indexes. If you are processing all of your data for all your queries then yes, click house sequential scans may be better. But that's less common, and also where TimescaleDB continuous aggregates come in.

We've seen customers successfully use our single-node version with 100s of billions of rows so claiming that we are just for small use-cases is simply untrue, and especially with the launch of multi-node TimescaleDB.

I understand people may have different preferences and experiences, but some of these felt a bit off to me.

[1] https://blog.timescale.com/blog/building-columnar-compressio...

I see, that makes a whole lot of sense. This is an interesting use-case. It actually may be possible to use some of the aggregates provided by the extension even with a different schema. If you are interested in exploring further, my username on slack is `mat` and my email is the same @timescale.com

The access node is replicated using streaming replication and is thus not a SPOF.

(TimescaleDB engineer) we hear you and are working on making continuous aggregations easier to use.

For now, the recommended approach is to perform continuous_aggregates on single tables and perform joins, order by, and window when querying the materialized aggregate rather than when materializing.

This often has the added benefit of often making the materialization more general so that a wider range of queries can use it.

You can look at what we use in our benchmarking tool https://github.com/timescale/tsbs (results described here https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...).

Pretty much it's a table with time, value, tags_id. Where the tags table is id, jsonb

(TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.

(TimescaleDB engineer) Actually, the reason we break out the Jsonb like this is because json blobs are big and take up a lot of space and so we normalize it out. This is the same thing that InfluxDB or Prometheus do under the hood. We also do this under the hood for Timescale-Prometheus.

If you have a data model that is slightly more fixed than Prometheus, you'd create a column per tag and have a foreign-key to the labels table. That's a pretty simple schema which would avoid a whole lot of complexity in here. So if you are developing most apps this isn't a problem and filtering on dimensions/tags/labels isn't a problem. Again, this is only an issue of you have very dynamic user-defined tags, as Prometheus does. In which case you can just use Timescale-Prometheus.

(TimescaleDB engineer here). This is a really unfair critique.

The project you cite is super-optimized for the Prometheus use-case and data model. TimescaleDB beats InfluxDB on performance even without these optimization. It's also not possible to optimize in this way in most other time-series databases.

These scripts also work hard to give users a UIUX experience that mimicks PromQL in a lot of ways. This isn't necessary for most projects and is a very specialized use-case. That takes up a lot of the 2000 lines you are talking about.