pauldix

8 ms·

31.
by pauldix 3y ago
Copyleft isn't permissive. It's a viral license that sets restrictions on derivative works, forks and contribution.
32.
by pauldix 3y ago
Revenue through hosting continues to be the big driver for all of these projects, which is what is motivating the license changes. The trend indicates that only open source libraries work for companies that own projects. If it's a prog
33.
Redis adopts dual source-available licensing(redis.com)
417 points by pauldix 3y ago|601 comments
34.
Run and manage open source InfluxDB databases with Amazon Timestream(aws.amazon.com)
2 points by pauldix 3y ago|0 comments
35.
Aligning Velox and Apache Arrow: Towards composable data management(engineering.fb.com)
1 points by pauldix 3y ago|0 comments
36.
Freenginx.org – open-source Nginx fork(freenginx.org)
100 points by pauldix 3y ago|2 comments
37.
by pauldix 3y ago
OMG we had half of the 4th floor of that building on sublease when the pandemic hit (and for 2 years prior). The week of the first lockdown in 2020 we were all set to sign a new long term lease for an entire upper floor and half of the one
38.
by pauldix 3y ago
To be honest I'm not sure. Upgrading individual releases on the way should take you there, but the v2 beta was quite a while ago.
39.
by pauldix 3y ago
With 3.0 we've worked hard to pull in the v1 API. Both the v1 write and query endpoints are supported in v3. There may some gaps here and there, but our goal is to make it so that all the things that worked with v1 will work with v3. T
40.
by pauldix 3y ago
InfluxDB v3 is built to handle this kind of data. It's a columnar database, using object storage and Parquet files for persistence.
41.
by pauldix 3y ago
A traditional monolithic database assumes that you have locally attached storage. All of your ingest, indexing and query processing happens on the machine with that storage (i.e. your compute and storage live together). The cloud kind of co
42.
by pauldix 3y ago
We announced the availability of the v3 successor to Enterprise v1. It supports the v1 API. We're still building data migration tooling, but if you're interested in testing it out just email support or your sales rep.
43.
by pauldix 3y ago
We're going to continue to support our customers on v1 and v2. We're building migration tooling over to v3 for those that want it. We have multiple years of transition ahead of us, we expect to have customers on all 3 versions for
44.
by pauldix 3y ago
Yes, the goal was that for anyone with Grafana dashboards or queries elsewhere, they wouldn't have to rewrite them. Just point at v3 and pretend that it's a v1 database (use the v1 API). But there are a few things that aren't
45.
by pauldix 3y ago
In this case, the features we kept getting asked for by our customers necessitated a change in underlying database architecture. I talk about that quite a bit in the reddit thread. I totally agree that a rewrite is risky. It's not some
46.
by pauldix 3y ago
For v3 we're supporting InfluxQL natively in addition to SQL. The InfluxQL implementation is actually just a front end on top of DataFusion, the SQL engine we use. We really wanted to bring Flux along too, but found that it was too dif
47.
by pauldix 3y ago
We're trying to make the transition from v1 to v3 easier by brining the write and query APIs from that version forward. We wanted to do the same for Flux, but found it was too difficult in the near term. We might be able to do somethin
48.
by pauldix 3y ago
So it sounds like you're asking about our use cases. We have customers across almost every vertical. But what's most common are application and server monitoring, sensor data (industrial, rockets, satellites, etc.), and network mo
49.
by pauldix 3y ago
It's definitely not something I'd do again. I'd warn off anyone from taking this approach. But the early results are looking good and I'm very excited about what this enables for the next few years ahead of us.
50.
by pauldix 3y ago
To be fair, we didn't drop everything and do a rewrite. Over the last 3.5 years (the length of time for this project), our total engineering team has ranged from 50-90 people. For the first year it was me and two other people. Then for
51.
by pauldix 3y ago
I still love Go, but I think Rust is a better fit for very performance sensitive systems software like a database.
52.
by pauldix 3y ago
We'll have to test Chronograf against 3.0, but I think it should just work. Unfortunately, we don't have the resources to continue developing it, but it's all available under a permissive MIT license here: https://
53.
by pauldix 3y ago
All versions will support infinite cardinality, including Edge and Community. That's a result of the database architecture.
54.
by pauldix 3y ago
I expect that one of the use cases for the embedded VM will be to downsample data so I think it's something you could do inside Edge.
55.
by pauldix 3y ago
I think Edge would be suitable for this use case. It's not that longer time period data won't be stored and queryable, it's just that Edge isn't optimized to make that longer period data queryable very fast (because it&#
56.
by pauldix 3y ago
Telegraf is still very much alive and well. With v3, we realized the scope of what we were trying to do in v2 was simply too large. We're putting our focus back on the core of the database. Having an embedded VM (it'll be either P
57.
by pauldix 3y ago
V3 will support the V1 API and there will be data migration tools for both v1 and v2 into v3. For our customers, we continue to support v1, v2 and v3 and will for quite some time.
58.
by pauldix 3y ago
With v3 we're bringing the v1 API into it so that people will be able to interact with it as if it were a v1 database. There will be data migration tools from both v1 and v2 into v3. We would have loved to bring the v2 API along, but u
59.
by pauldix 3y ago
The git history was preserved. There aren't really any external contributions to speak of. We've been the sole developers of IOx/InfluxDB 3.0 over the last 3.5 years.
60.
by pauldix 3y ago
Hi, post author and founder of InfluxDB. Happy to answer questions here.

More ›