ignaciovdk

11 ms·

1.
by ignaciovdk 29d ago
No, and with timescaledb is a feature of their cloud platform. For on prem you can use something like Arc: https://github.com/Basekick-Labs/arc
2.
by ignaciovdk 1mo ago
I don't know, my gut says that this is going to end in a bad way. I signed up, I think but wasn't sure if I needed to buy Cursor, or Origin came with a subscription, so confused. For now Arc is staying in Github: https:/&#x2
3.
by ignaciovdk 1mo ago
Hey hey. I love to. I'm from Argentina, and I say that Arc is proudly make from Latam, but I live in Costa Rica.
4.
by ignaciovdk 1mo ago
Arc does pruning, and make that scan faster. Check it out: https://github.com/Basekick-Labs/arc
5.
by ignaciovdk 1mo ago
Check it out Arc, I think that we can help there, plus, use DuckDB as a engine: https://github.com/Basekick-Labs/arc
6.
by ignaciovdk 2mo ago
Very cool!
7.
by ignaciovdk 9mo ago
We (Basekick Labs) we are the new maintainers of Liftbridge. It went dormant in 2022, and we're reviving it. Liftbridge adds Kafka-style durability to NATS: commit log, partitions, ISR replication. Single Go binary, no JVM or ZooKeeper
8.
Liftbridge – Kafka-style streams in Go, built on NATS(github.com)
1 points by ignaciovdk 9mo ago|1 comments
9.
by ignaciovdk 11mo ago
Arc is OSS under AGPL-3.0: https://github.com/Basekick-Labs/arc
10.
Show HN: Metrics, Logs, Traces and Events in One Place. This Is Arc
3 points by ignaciovdk 11mo ago|1 comments
11.
by ignaciovdk 11mo ago
Two weeks ago, we open-sourced Arc Core: https://github.com/Basekick-Labs/arc Today, the results are in, Arc is now the fastest time-series database on ClickBench, outperforming QuestDB and TimescaleDB across nearly ev
12.
Arc: One week later, 210 stars and new ClickBench results
1 points by ignaciovdk 11mo ago|0 comments
13.
by ignaciovdk 11mo ago
That’s fair, the number alone doesn’t mean much without context. The benchmark measures fully written time-series records, not bytes. Each record typically includes 1–4 fields, tags, and timestamps, similar to InfluxDB’s Line Protocol struc
14.
by ignaciovdk 1y ago
Thanks! Let’s go by parts, as Jason would say Schema inference: yes, Arc infers the schema automatically from incoming data (both for MessagePack and Line Protocol). Each measurement becomes a table, and fields/tags map to columns. Sch
15.
by ignaciovdk 1y ago
Hey, thanks for asking. I’d say both roles are possible, though the original intent of Arc was indeed to act as an offload / long-term store for systems like TimescaleDB, InfluxDB, Kafka, etc. The idea: you send data into Arc to reduce
16.
by ignaciovdk 1y ago
Great questions, thanks! Partitioning: yes, Arc partitions by measurement > year > month > day > hour. This structure makes time-range queries very fast and simplifies retention policies (you can drop by hour/day instead of
17.
by ignaciovdk 1y ago
Hey there, great questions. The benchmarks weren’t run on the same machine as MinIO, but on the same network, connected over a 1 Gbps switch, so there’s a bit of real network latency, though still close to local-disk performance. We’ve also
18.
by ignaciovdk 1y ago
Awesome, would love to hear what you think once you try it out! If it’s not too much trouble, feel free to share feedback at ignacio [at] basekick [dot] net.
19.
by ignaciovdk 1y ago
Hey, good question! I didn’t really worry about confusion since this isn’t a browser, it’s a completely different animal. The name actually came from “Ark”, as in something that stores and carries, but I decided to go with Arc to avoid soun
20.
Show HN: Arc – high-throughput time-series warehouse with DuckDB analytics(github.com)
30 points by ignaciovdk 1y ago|19 comments
21.
Show HN: Historian – bridge from InfluxDB 1.x/2.x to 3.0 with Parquet and DuckDB(cduser.com)
1 points by ignaciovdk 1y ago|0 comments
22.
Show HN: Basekick – We rescue AI startups from broken infra (CI/CD, AWS, etc.)(basekick.net)
1 points by ignaciovdk 1y ago|0 comments
23.
Show HN: Tiered storage and fast SQL for InfluxDB 1.x/2.x(historian.exydata.com)
4 points by ignaciovdk 1y ago|0 comments
24.
by ignaciovdk 1y ago
That’s a fair question, and in theory, yes, you could manually track internal certs based on issue date. But in practice, large or long-running environments rarely have clean cert inventories. You get: - Internal CA sprawl (and no single so
25.
by ignaciovdk 1y ago
Totally fair, and for a single cert or a tightly controlled setup, a calendar reminder might be “enough.” But in practice, it tends to break down when: - Certificates multiply across internal services, vendors, CDNs, load balancers, staging
26.
by ignaciovdk 1y ago
We're building a lightweight collector (RTCollector) you can run inside the air-gapped environment. It can read from local cert stores (JKS, PKCS#12, PEM, etc.), extract metadata like expiration date and fingerprint (no private keys or
27.
by ignaciovdk 1y ago
Totally fair, for public-facing web servers, Traefik, Caddy, and Let’s Encrypt have made things nearly zero-effort. It’s amazing how far we’ve come. That said, a lot of enterprise environments still deal with: - Air-gapped networks (no LE&#
28.
by ignaciovdk 1y ago
That’s a sentiment I hear a lot, and honestly, not without reason. The trust model behind public CAs is… fragile at best. Misissuances, opaque root store politics, and uneven auditing make it feel like we’re outsourcing security to a cartel
29.
by ignaciovdk 1y ago
Absolutely, this shift toward shorter cert lifetimes is going to make monitoring even more critical. Automation will help, but with 90-, 100-, and eventually 47-day cycles, the margin for unnoticed renewal failures shrinks fast. One bad dep
30.
by ignaciovdk 1y ago
You’re absolutely right, SSL monitoring isn’t a new problem. Tools like Nagios, Zabbix, and many SaaS providers have offered uptime and cert checks for years. What I found lacking (especially for modern teams) was: - Multi-domain, multi-ten

More ›