potygen VS tenzir

OMG this is one of my favorite tools paid for it all the way back when it went out. Have used it so many times just to write documentation for things like:

https://github.com/ivank/potygen/blob/main/packages/potygen/...

ASCII is just so versatile and allows you to put nice graphics in places where one does not expect, making things more easily understandable.

I also wrote a parser (in typescript) for postgres (https://github.com/ivank/potygen), and it turned out quite the educational experience - Learned _a lot_ about the intricacies of SQL, and how to build parsers in general.

Turned out in webdev there are a lot of instances where you actually want a parser - legacy places where they used to save things in plane text for example, and I started seeing the pattern everywhere.

Where I would have reached for some monstrosity of a regex to solve this, now I just whip out a recursive decent parser and call it a day, takes surprisingly small amount of code! (https://github.com/dmaevsky/rd-parse)

I used to agree 100% with this sentiment, as dissatisfaction with available ORMs at the time (early days of doctrine in PHP) drove me to actually write my own. Turned out an amazing exercise in why orms are hard.

Anyway a few years later I was in a position to start things fresh with a new project so thought to myself, great lets try to do things right this time - so went all the way in the other direction - raw sql everywhere, with some great sql analyzer lib (https://github.com/ivank/potygen) that would strictly type and format with prettier all the queries - kinda plugged all the possible disadvantages of raw query usage and was a breeze to work with … for me.

What I learned was that ORMs have other purposes - they kinda force you to think about the data model (even if giving you fewer tools to do so) With the amount of docs and tutorials out there it allows even junior members of the team to feel confident about building the system. I’m pretty used to sql, and thinking in it and its abstractions is easy for me, but its a skill a lot of modern devs have not acquired with all of our document dbs and orms so it was really hard on them to switch from thinking in objects and the few ways orms allows you to link them, to thinking in tables and the vast amounts of operations and dependencies you can build with them. Indexable json fields, views, CTEs, window functions all that on top of the usual relation theory … it was quite a lot to learn.

And the thing is while you can solve a lot of problems with raw sql, orms usually have plugins and extensions that solve common problems, things like soft delete, i18n, logs and audit, etc. Its easy even if its far from simple. With raw sql you have to deal with all that yourself, and while it can be done and done cleanly, still require intuition about performance characteristics that a lot of new devs just don’t possess yet. You need to be an sql expert to solve those in a reasonable manner m, just an average dev could easily string along a few plugins and call it a day. Would it have great performance? Probably not. Would it hold some future pitfalls because they did not understand the underlying sql? Absolutely! But hay it will work, at least for a while. And to be fair they would easily do those mistakes with raw sql as well, but with far few resources to understand why it would fail, because orms fail in predictable ways and there is usually tons of relevant blog posts and such about how to fix it.

It just allows for an better learning curve - learn a bit, build, fail, learn more, fix, repeat. Whereas raw sql requires a big upfront “learn” cost, while still going through the “fail” step more often than not.

Now I’m trying out a fp query builder / ORM - elixir’s ecto with the hopes that it gives me the best of both worlds … time will tell.

We're building something similar at Tenzir, but more for operational security workloads. https://docs.tenzir.com

Differences to Vector:

- An agent has optional indexed storage, so you can store your data there and pick it up later. The storage is based on Apache Feather, Parquet's little brother.

- Pipelines operators both work with data frames (Arrow record batches) or chunks of bytes.

- Structured pipelines are multi-schema, i.e., a single pipeline can process streams of record batches with different schemas.

Tenzir | Remote (EU) or Hamburg, Germany | open-core | Full-time | https://tenzir.com

Tenzir is hiring several key engineering roles to meet the needs in expanding the team. Our product: security data pipelines. From the data side, think of it as an Arrow-native, multi-schema ETL tool that offers optional storage in Parquet/Feather. From the security perspective, think of it as a solution for collecting, parsing, transforming, aggregating, and routing data. We typically sit between the data sources (endpoint, network, cloud) and sinks (SIEM, data lake).

Our open-source execution engine is C++20 (https://github.com/tenzir/tenzir), our platform is SvelteKit and TypeScript. Experience with data-first frontend apps is a great plus. Open positions at https://tenzir.jobs.personio.de:

    - Fullstack Engineer

We're in the middle of getting TQL v2 [] out of the door with support for expressions and more advanced control flow, e.g., match-case statements. There's a blog post [#] about the core design of the engine as well.

While it's a general-purpose ETL tool, we're targeting primary operational security use case where people today use Splunk, Sentinel/ADX, Elastic, etc. So some operators are very security'ish, like Sigma, YARA, or Velociraptor.

[] https://github.com/tenzir/tenzir/blob/64ef997d736e9416e859bf...

[#] https://docs.tenzir.com/blog/five-design-principles-for-buil...

Hey, founder of Tenzir [1] here — We are building an open-core pipeline-first security data engine that can massively reduce your Splunk costs. Even though we go to market "mid stream" we have a few users that use us as light-weight SIEM (or more accurately, just plain log management).

We are still in early access to browse through our docs or swing by our Discord.

[1] https://tenzir.com | https://docs.tenzir.com

Download VAST v3.1 here: https://github.com/tenzir/vast/releases/tag/v3.1.0

Tenzir is a funded seed-stage startup that builds a next generation data-plane for plug-and-play security operations. Our mission is to empower defenders with an open data engineering platform to perform data-driven investigations through combination best-of-breed solutions. Our stack consists of the high-performance C++20 telemetry engine VAST, a Rust API, and a ReasonML-based frontend.

I had chat with Hannes, the DuckDB co-founder, a few weeks ago. They are building awesome stuff to become the "SQLite of OLAP". The team comes with a strong academic background and is tuned into the data engineering world.

At Tenzir, we looked at DuckDB as embeddable backend engine to do the heavy lifting of query execution of our engine [1]. Our idea is throwing over a set of Parquet files, along with a query; initially SQL but perhaps soon Substrait [2] if it picks up.

We also experiment with a cloud deployment [3] where a different set of I/O path may warrant a different backend engine. Right now, we're working on a serverless approach leveraging Datafusion (and depending on maturity, Ballista at some point).

My hunch is that we will see more pluggability in this space moving forward. It's not only meaningful from an open-core business model perspective, but also pays dividends to the UX. The company that's solving a domain problem (for us: security operations center infrastructre) can leverage a high-bandwidth drop-in engine and only needs to wire it properly. This requires much less data engineers than building a poorman's version of the same inhouse.

We also have the R use case, e.g., to write reports in Rmarkdown that crunch some customer security telemetry, highlighting outliers or other noteworthy events. We're not there yet, but with the right query backend, I would expect to get this almost for free. We're close to being ready to use Arrow Flight for interop, but it's not zero-copy. DuckDB has demonstrated the zero-copy approach recently [4], going through the C API. (The story is also relevant when doing s/R/Python/, FWIW.)

[1] https://github.com/tenzir/vast

To this end, we build the high-performance telemetry engine VAST, which at its core, ingests hundreds of thousands of events per second from high-volume data sources (such as network telemetry as NetFlow, Zeek, Suricata, and endpoint telemetry from various agents). To the user, VAST offers low-latency access through various APIs, and in particular Apache Arrow for high-bandwidth data sharing with downstream tooling. A flexible plugin API enables additional security-specific use cases on top, such as realtime matching of threat intelligence or mining of asset data for passive inventorization.

Tenzir | C++, ReasonML, Rust, Python | Remote | Open-source | Full-time | https://tenzir.com

Tenzir is a funded seed-stage startup that builds a next generation data-plane for plug-and-play security operations. Our mission is to empower defenders with an open platform to perform automated data-driven investigations through combination best-of-breed solutions. Our stack consists of the high-performance C++ database VAST (https://github.com/tenzir/vast), a Rust API, and a ReasonML-based frontend.

Our open engineering positions include:

- Database: https://tenzir.com/career/backend-engineer/

- DevOps: https://tenzir.com/career/devops-platform-engineer/

- Frontend: https://tenzir.com/career/frontend-engineer/

We are based out of Hamburg, Germany, but cultivate an agile remote-first mindset. If you live in the region and look for a System Administrator, we’d love to hear from you!

For any questions, feel free to reach out to us at [email protected].

We at Tenzir (https://tenzir.com/) are an early-stage startup that build a next generation data-plane for modern Security Operations Centers. We are looking for a frontend engineer to help us enhance the web interface to VAST (our open-core telemetry engine, https://github.com/tenzir/vast). In our stack, we use C++ for VAST , Rust and ReasonML (compiled to JS) in our API-Layer, and ReasonML on the frontend. Our website is written in ReasonML with the help of Gatsby. Our team cultivates a mindset of strong typing and functional programming, practiced end-to-end across the entire stack. We're a remote-first company, scattered across Europe. Ideally looking for someone within (+ / -) 4hrs timezone.