Language-Natural Persistence Layer for Java (by permazen)

Permazen Alternatives

Similar projects and alternatives to Permazen

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better Permazen alternative or higher similarity.

Permazen discussion

Log in or Post with

Permazen reviews and mentions

Posts with mentions or reviews of Permazen. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-02-01.
  • ORMs are nice but they are the wrong abstraction
    7 projects | | 1 Feb 2024
    The most interesting/fresh approach I've seen to this problem is Permazen.

    It starts by asking what the most natural way is to integrate persistence with a programming language (Java in this case, but the concepts are generic), and then goes ahead and implements the features of an RDBMS as an in-process library that can be given different storage backends as long as they implement a sorted K/V store. So it can sit on top of a simple in-process file based K/V store, RocksDB, FoundationDB, or any SQL database like PostgreSQL, SQLite, Spanner, etc (it just uses the RDBMS to store sorted key/value pairs in that case).

    Essentially it's a way to map object graphs to key/value pairs but with the usual features you'd want like indexing, validation, transactions, and so on. The design is really nice and can scale from tiny tasks you'd normally use JSON or object serialization for, all the way up to large distributed clusters.

    Because the native object model is mapped directly to storage there's no object/relational mismatch.

  • Permazen: Language-natural persistence to KV stores
    6 projects | | 19 Sep 2023
    Ok, let's change to that from above.

    Usually we go the other way and prefer the project page, but there's clearly not enough info there.

  • How FoundationDB works and why it works
    5 projects | | 18 Sep 2023
  • Figma Is a File Editor
    3 projects | | 13 Jul 2023
    You can use a scalable database that gives you serializable transactions whilst not requiring you to represent your document in the relational model.

    A good example of this architecture would be using FoundationDB [1] with Permazen [2]. In this design there are three layers:

    1. A horizontally scaling sorted transactional K/V store. This is provided by FoundationDB. Transactions are automatically ordered within the cluster.

    2. A network protocol that can serialize database transactions. Permazen has the ability to do this, you can do things like cache reads, HTTP POST transactions and so on. Stuff you can't easily do with SQL databases.

    3. A way to map in-memory objects to/from key/value pairs, with schema migration, indexing and other DB-like features. Permazen also does this.

    Permazen can be thought of as an ORM for KV stores. It's an in-memory library intended to execute on trusted servers (because the KV store can't do any business logic validation). However, for something like Figma where it's basically trusting the client anyway that doesn't matter. Additionally you can do some tricks with the architecture to support untrusted clients; I've explored these topics with Archie (the Permazen designer) in the past.

    The nice thing about this design is that it doesn't require sharding by "file", can scale to large numbers of simultaneous co-authors, and results in a very natural coding model. However, Permazen is a Java library. To use it from a browser would be awkward. That said it has fairly minimal reliance on the JDK. You could probably auto-convert it to Kotlin and then use Kotlin/JS or Kotlin/WASM. But frankly it'd be easier to do that architecture as a real desktop app where you aren't boxed in by the browser's limitations.

    The writeup mentions a couple of reasons for not using a database:

    1. Relational/object mismatch. Permazen+FDB solves this.

    2. Cost of a database vs S3. This is mostly an artifact of cloud pricing. Cloud is highly profitable but most of the margin comes from managed databases and other very high level services, not commodity byte storage. Given that FDB is free you could eliminate the cost gap by just running the database yourself, and especially, running it on your own metal.

    Because Permazen has a pluggable KV backend and because there are backends that write to files, you can have both worlds - a scalable DB in the cloud and also write to files for individual cases where people don't want to store data on your backend. [1] [2]

  • FoundationDB: A Distributed Key-Value Store
    13 projects | | 3 Jul 2023
    You can do online schema changes with FDB, it all depends on what you do with the FDB primitives.

    A great example of how to best utilize FDB is Permazen [1], described well in its white paper [2].

    Permazen is a Java library, so it can be utilized from any JVM language e.g. via Truffle you get Python, JavaScript, Ruby, WASM + any bytecode language. It supports any sorted K/V backend so you can build and test locally with a simple disk or in memory impl, or RocksDB, or even a regular SQL database. Then you can point it at FoundationDB later when you're ready for scaling.

    Permazen is not a SQL implementation. Instead it's "language integrated" meaning you write queries using the Java collections library and some helpers, in particular, NavigableSet and NavigableMap. In effect you write and hard code your query plans. However, for this you get many of the same features an RDBMS would have and then some more, for example you get indexes, indexes with compound keys, strongly typed and enforced schemas with ONLINE updates, strong type safety during schema changes (which are allowed to be arbitrary), sophisticated transaction support, tight control over caching and transactional "copy out", constraints and the equivalent of foreign key constraints with better validation semantics than what JPA or SQL gives you, you can define any custom data derivation function for new kinds of "index", a CLI for ad-hoc querying, and a GUI for exploration of the data.

    Oh yes, it also has a Raft implementation, so if you want multi-cluster FDB with Raft-driven failover you could do that too (iirc, FDB doesn't have this out of the box).

    FDB has something a bit like this in its Record layer, but it's nowhere near as powerful or well thought out. Permazen is obscure and not widely used, but it's been deployed to production as part of a large US 911 dispatching system and is maintained.

    Incremental schema evolution is possible because Permazen stores schema data in the K/V store, along with a version for each persisted object (row), and upgrades objects on the fly when they're first accessed.



  • Warp: Lightweight Multi-Key Transactions for Key-Value Stores
    5 projects | | 29 May 2022
  • Persism 1.0.1 released - A zero ceremony ORM for Java
    3 projects | /r/java | 2 Mar 2021
    Compare to ?
  • Introducing Weightless, an extremely easy to use database mapping library for Java
    2 projects | /r/java | 31 Jan 2021
    Did you see - it's in the same space
  • A note from our sponsor - InfluxDB | 22 Jul 2024
    Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →


Basic Permazen repo stats
15 days ago

Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

Did you konow that HTML is
the 11th most popular programming language
based on number of metions?