adsharma

8 ms·

31.
by adsharma 2mo ago
If you must use Django, use it through an abstraction layer like this: https://adsharma.github.io/django-fquery/ Your models can be plain old python data classes, declaratively mapped to Django primitives.
32.
by adsharma 2mo ago
- Installing a db these days is not prohibitive. You don't have to hire a DBA curl <url> | bash - Some graph databases allow you to query a relational source without migrating data
33.
by adsharma 2mo ago
The reason for not recommending networkx is the choice it offers: fast on the GPU: nx-cugraph slow on the CPU: networkx (no arrow, see linked graph-benchmark) I'm looking to offer something that's best in class on both CP
34.
by adsharma 2mo ago
There is a bit of healthy competition going on between graphframes and icebug. See: https://github.com/Ladybug-Memory/icebug-graphframes-compari... I thought of datafusion work and the rust implementation as a way to a
35.
by adsharma 2mo ago
They use networkx today: https://github.com/rapidsai/nx-cugraph/ because it's more popular than networkit or icebug. But its popularity is based on ease of use, not performance: https://github.com&
36.
by adsharma 2mo ago
I'm happy to credit these people. https://arrow.apache.org/docs/r/authors.html CUDA and the ecosystem around it is more complicated. I'll use it. I agree that it advanced the state of the art and helped
37.
by adsharma 2mo ago
Ofc. I'm not claiming credit for Apache Arrow. Lots of people contributed to it. I didn't write the graph algorithms in networkit. Somebody else did. But if you're looking for 100-200 graph algorithms running efficiently on c
38.
by adsharma 2mo ago
It looks similar to networkit in that it represents graphs using row oriented memory layout. I forked networkit for exactly this reason. Columnar memory is much more efficient.
39.
by adsharma 2mo ago
Here is a proposal built on parquet/arrow. What other alternatives exist that can be queried by a database without ingest? https://github.com/Ladybug-Memory/icebug-format
40.
by adsharma 2mo ago
https://github.com/LadybugDB/ladybug-icebug-notebooks/blob/m... Trade-off: datafusion allows you to do fine grained storage integration (spill to disk as a part of the algorithm). The icebug/ladybug way
41.
by adsharma 2mo ago
The idea of graph algorithms on Apache arrow at scale originated here. 100+ graph algorithms running on columnar memory. https://github.com/Ladybug-Memory/icebug Out of core with datafusion is the main innovation here
42.
by adsharma 2mo ago
DuckDB also implements MVCC. In DuckLake, the DB is used for absorbing small writes and compacting them before sending to object storage. It has some characteristics typical of OLTP engines. But they are targeted and limited to areas DuckDB
43.
by adsharma 2mo ago
SQLite can be replicated. rqlite, dqlite, litestream etc DuckDB can't be. PR was sent a year ago. Blocked on the same concurrency model issue in the other sub thread. Specifically on windows, the database can't read its own WAL f
44.
by adsharma 3mo ago
Many recent graph databases are built like this. If you compare ladybugdb vs duckdb, the internals are very similar. The main innovation is the "REL table". You can think of it as a many-to-many relationship table on steroids with
45.
by adsharma 3mo ago
Just use postgres (or another SQL db) ignores the following innovations: * Columnar storage * Compressed Sparse Row on disk * Factorized joins * ASP joins, WCO Joins Details: https://vldb.org/cidrdb/2023/kuzu-graph
46.
by adsharma 3mo ago
Recent benchmarking: https://theconsensus.dev/p/2026/05/29/ladybug-duckdb-and-pos... Response: https://blog.ladybugdb.com/post/better-graph-database-ball/
47.
by adsharma 3mo ago
There are several MIT/Apache licensed embedded graph databases available, including the one linked from my profile.
48.
by adsharma 3mo ago
Just in case you find the earlier message too cryptic. It's not performing well on web search. https://pypi.org/project/tsc-py/
49.
by adsharma 3mo ago
Need something for backward compatible RPC? Use protobuf. But for storage and types? This is where I feel there are better alternatives. If you go with protobuf, you're picking 2 out of 3: simplicity, fast, idiomatic. Please consider &
50.
LadybugDB Flying Solo(blog.ladybugdb.com)
1 points by adsharma 3mo ago|1 comments
51.
by adsharma 3mo ago
LadybugDB was forked from KuzuDB 8 months ago. Find out what's new and how it differs from KuzuDB in performance, features and market positioning.
52.
by adsharma 3mo ago
A more appropriate mirror test for LLMs is to get them to state facts about their training data. Percentage of arts vs science for example. Given the framing that they're similar to nukes and a national security issue, it's likely
53.
by adsharma 4mo ago
It's interesting that the blog post places SQLite and Ladybird on the spectrum, but omits it's chief open source rival: DuckDB. Agree that Level 3 is what inspires confidence. But we need to invent new business models to sustain i
54.
by adsharma 4mo ago
DuckDB and LadybugDB use the same terminology to describe internals.
55.
by adsharma 4mo ago
The future is to write Rust in a python interpreter compatible way leveraging large parts of the python ecosystem. This will require minor tweaks to the language and perhaps a forked interpreter (a forked parser already exists). Then you so
56.
by adsharma 4mo ago
7 years of python -> rust here. https://github.com/py2many/static-python-skill/blob/main/ass...
57.
by adsharma 5mo ago
Installing thing like this should be an agent skill, not a distribution.
58.
by adsharma 5mo ago
+1 - I was making exactly this argument in other threads. But I have a slightly different take on how software should be written. Translating zig -> rust is more complex than writing a JPEG parser in static python and then lowering it in
59.
by adsharma 5mo ago
A SMT solver may work better.
60.
Show HN: Vpg – Pglite for Native Code(github.com)
1 points by adsharma 5mo ago|0 comments

More ›