akulkarni

7 ms·

31.
by akulkarni 2y ago
YMMV but our largest internal dogfooded Timescale instance is 100s of terabytes https://www.timescale.com/blog/how-we-scaled-postgresql-to-3... (Post is a year old, IIRC the database is over one petabyte now)
32.
by akulkarni 2y ago
Exactly. You can have the best of both worlds with Timescale.
33.
by akulkarni 2y ago
That's interesting. Our first extension (TimescaleDB) is great for time-series and real-time analytics. And yes you are correct, pgvectorscale scales pgvector for embeddings, and pgai includes dev experience niceties for AI (eg automat
34.
Why is everyone trying to replace Software Engineers?(toddle.dev)
73 points by akulkarni 2y ago|139 comments
35.
by akulkarni 2y ago
You can request it for RDS
36.
Vector Databases should be Vector Indexes(twitter.com)
4 points by akulkarni 2y ago|0 comments
37.
Google's AlloyDB Now Available on Other Clouds(aiven.io)
4 points by akulkarni 2y ago|0 comments
38.
Notion AI(twitter.com)
1 points by akulkarni 2y ago|0 comments
39.
Every GitHub Repository Should Be a Dataset(opensauced.pizza)
1 points by akulkarni 2y ago|0 comments
40.
by akulkarni 2y ago
Agreed :-)
41.
by akulkarni 2y ago
pgvectorscale only makes pgvector better. The primary developer-facing improvement is the introduction of the StreamingDiskANN index type. So we would recommend using both from the start. There is no cost (technical or financial) for doing
42.
by akulkarni 2y ago
Ajay, Timescale CEO and co-founder, here. It saddens me to see that we have generated so much ill will from you. It sounds like you were affected by our layoffs last year. You have every right to be upset. If you ever want to chat about thi
43.
by akulkarni 2y ago
You don't need to imagine ;-) https://x.com/avthars/status/1788195573989806448
44.
by akulkarni 2y ago
(Timescale co-founder) James did put a lot of thought into this post. I saw multiple iterations of it before it was published. I think calling it a shitpost is being unkind to him. I think we just find that some developers don't like r
45.
by akulkarni 2y ago
(Timescale co-founder) We actually have 100s of customers who use Timescale for their production time-series _and_ OLTP workloads :-)
46.
Simon Willison thoughts on GPT-4o(simonwillison.net)
3 points by akulkarni 2y ago|0 comments
47.
by akulkarni 4y ago
Thanks! Happy to put you in touch with someone to help you migrate. Or at least, to help you calculate how much cost you could save :-) ajay (at) timescale (dot) com
48.
by akulkarni 4y ago
(Timescale co-founder) Let us know how we can help :-) Also just curious: What's your application?
49.
by akulkarni 4y ago
(Timescale co-founder) As with anything, it depends on what you want to do. If you have an OLAP heavy workload with long scans, etc (which is the type of queries prominent on the ClickHouse page - e.g., Q0 is "SELECT COUNT(*) FROM hits
50.
by akulkarni 4y ago
(Timescale co-founder) Just to clarify: Nothing on Timescale is closed-source. It is all source available, all on Github. Some of it is Apache2 licensed, some of it is Timescale Licensed. And it is all free.
51.
by akulkarni 4y ago
(Timescale co-founder) Yes, 100%. We deliberately choose the "+" symbol instead of "vs." for this blog title. We love PostgreSQL. :-)
52.
by akulkarni 4y ago
(Timescale co-founder) That's a fair question. We find that most developers storing time-series data on Postgres are doing so without pg_partman. So we first wanted to provide a benchmark that would be useful to most developers. This b
53.
by akulkarni 4y ago
[Timescale co-founder] We have published many, many benchmarks versus other database systems. IIRC all of them also made the front page of HackerNews. Here are some of them, for your reading pleasure :-) TimescaleDB vs. InfluxDB: https:&#x
54.
by akulkarni 4y ago
"One of these things is not like the other" TimescaleDB, because it is packaged as a PostgreSQL extension (and not a fork, unlike the others), stays compatible with mainline PostgreSQL, especially as PostgreSQL improves. This is o
55.
by akulkarni 4y ago
clickhouse is more generally olap and not suitable for oltp, you could call it an olap+timeseries solution similarly to how you position timescale as oltp+timeseries You are correct, TimescaleDB is time-series + OLTP. But I would
56.
by akulkarni 4y ago
Time-series queries are faster on TimescaleDB (built on PostgreSQL) than ClickHouse. https://www.timescale.com/blog/what-is-clickhouse-how-does-i... Disclaimer: Timescale co-founder
57.
by akulkarni 4y ago
Results of query benchmarking between TimescaleDB [built on PostgreSQL] and ClickHouse. TimescaleDB outperforms in almost every query category I don’t think that post says what you think it says ;-) (Disclaimer, Timescale co-founder
58.
by akulkarni 4y ago
(Timescale co-founder) The Promscale team is at KubeCon right now, so I'll jump in to answer this question. Yes, you can actually cross-analyze traces with prometheus metrics in Promscale. That in fact is one of the key reasons we buil
59.
by akulkarni 5y ago
Thank you! I shared it with the team
60.
by akulkarni 5y ago
Thank you for the wonderful guest post (and the kind words!)

More ›