{ "version": "https://jsonfeed.org/version/1", "title": "michalwa | Michał Wawrzynowicz", "description": "Hi there! This is my personal website and blog where I hope to share personal projects and thoughts on programming, music, philosophy, and other interesting things.", "home_page_url": "https://michalwa.github.io/", "feed_url": "https://michalwa.github.io/feed.json", "author": { "name": "Michał Wawrzynowicz "}, "items": [ { "id": "https://michalwa.github.io/2026/07/13/ruby-learnings", "url": "https://michalwa.github.io/2026/07/13/ruby-learnings.html", "title": "Lessons Learned After 4+ Years of Ruby on Rails", "content_html": "

Lessons Learned After 4+ Years of Ruby on Rails

\n\n

Introduction

\n\n

Until recently, I was a professional Ruby developer for over 4 years. Before that, I had used the language occasionally for small personal projects or learning. To be honest, it’s never been quite up my alley. But when I was starting out, I assumed that my feelings about technologies should be put aside and that I should rather focus on building things. I still believe that to a certain extent, and I’m not saying goodbye to Ruby for good, but my opinions have matured over the years into more and more certain convictions.

\n\n

I actually got into Ruby quite late, its popularity already being long in decline. I mostly worked on projects which had been started years before. Rails projects specifically. I was never really interested in participating in the community aside from what I needed to do my job. The philosophy behind the language was also never really anything to write home about for me.

\n\n

I do think Ruby is a good scripting language. I think it’s my favorite among those, actually. The one thing I can honestly praise it for the most is how it fully takes advantage of being an interpreted language. It’s unlikely you’ll find object-oriented runtime metaprogramming/reflection this poweful anywhere else. You can totally bend this language to your will. This unfortunately ends up being one of the nails in its coffin when it hits production.

\n\n

It’s also worth mentioning that the language itself as a tool is actually not to blame for many of the shortcomings I’ll describe here. Some of the criticism is perhaps more appropriately aimed at Rails specifically, rather than Ruby. But I think the nature of my complaints still demonstrates how, ultimately, the practical Ruby experience involves patterns that are problematic in the long run. And I think, in this sense, the way a language is used—all the various conventions and philosophies around it, as well as its major frameworks and libraries—end up largely defining what the language actually is.

\n\n

I will also clarify that I’m intentionally not accounting for the historical context of Ruby’s development. I am simply assuming the perspective of a modern-day engineer with reasonable expectations for an actively maintained programming language and ecosystem.

\n\n

Pain

\n\n

I want to take ActiveRecord as an example, because I think it really shows the worst sides of this language and ecosystem. It’s an ORM and it makes heavy use of dynamic method generation. One particular feature it provides is implicit generation of scope methods for enum attributes. Say you have the following model:

\n\n
class Post < ActiveRecord::Base\n  enum :status, %i(draft published)\nend\n
\n\n

This will implicitly generate the following class methods:

\n\n\n

All of which return an appropriate collection/relation object.

\n\n

This is all fun and games (is it really?) until you need to debug something and you see such a method called out in the wild. Imagine seeing the following code:

\n\n
filtered_posts.not_published\n
\n\n

Imagine inspecting the resulting SQL and finding that it performs some filtering you never intended.

\n\n

Now to even know where to look for the definition you need to either assume that filtered_posts corresponds to the Post class purely by mentally parsing and matching the name, or navigate to the definition of filtered_posts to see what it actually returns.

\n\n

You could be lucky and find filtered_posts referencing the Post class, applying some scoping, and returning the resulting relation… or you might find something like this:

\n\n
def filtered_posts\n  if some_condition\n    Post.filter(...)\n  else\n    Article.filter(...)\n  end\nend\n
\n\n

Now the code analysis path diverges. This pattern may continue indefinitely.

\n\n

When you do miraculously arrive at the Post class, what do you do? Do you search for the definition of a method called not_published? No luck. What you have to do is know the format of the identifier that ActiveRecord may generate for a particular enum value and either know that such an enum exists or blindly search for published in hopes of finding it.

\n\n

This is a contrived example, so I don’t know what the ultimate issue could be here. Perhaps you find that published is actually a variant on a different attribute than the one you intended to filter by… You get the picture.

\n\n

Mind you, Ruby’s design philosophy supposedly maximizes programmer joy. I will proudly admit I got very good at this kind of stuff over the years, but it became increasingly difficult to find any joy in it.

\n\n

Greppability disaster

\n\n

Greppability is a metric of how well a codebase can be navigated using basic text search (or grep). It’s effectively inversely proportional to how often you will find yourself lost in the ways I mentioned earlier.

\n\n

There are several stages to what I would simply call a kind of obfuscation, but let’s call it anti-greppability to be specific:

\n\n
    \n
  1. Symbols are generated by concatenating user-provided symbols with pre-determined affixes. Take the example from above, published gets transformed into not_published. This is not even that disruptive once you get used to it, because the original identifier is still contained within the generated one, and you can sort of get by in the ways I mentioned earlier.
    2. \n
  2. Symbols are generated by inflecting user-provided symbols. This is a bizarre feature of Rails, where you call a model Product and the table name implicitly defaults to products. This wouldn’t be significant if not for the fact that special cases like Child are correctly inflected and become children, same for Person to people, etc. You have to ask yourself: Why? Would it really be so bad to require explicitly specifying the table name?
    3. \n
  3. Symbols are generated completely dynamically. If you’re coming from another language you might think this is a joke, but ActiveRecord, as many other Ruby libraries, generates methods based on a completely dynamic, statically opaque source, namely the database schema. And one which is only very loosely ensured to be uniform across environments. So the meaning of your code may effectively change depending on where it runs…
    4. \n
\n\n

Keep in mind, these mechanisms are used in Rails seemingly just because they can be used. I see no way in which they’re vital to the design of the framework. There are many other frameworks and libraries which make use of such patterns. The mere fact that it’s possible to do this in this language seems to encourage it among framework designers.

\n\n

Most of this is also configurable, of course. You could very well override some of the dynamically generated symbols with explicit configuration if you wanted to. However, Rails discourages this and nobody ever does this.

\n\n

Rails has a problematic interpretation of convention over configuration which falls apart as soon as you realize that convention is not always sufficient and configuration is still possible, which in turn makes convention unreliable. Without very rigorous code review you will always end up with half your models relying on convention and half configured with overrides or even your own metaprogramming… You end up spending hours figuring out “Is this something generated by Rails or should I look for the definition in our code?” So in a way the philosophy actually ends up nurturing the confusion it’s advertised to solve.

\n\n

To me, all of this paints a picture of a completely impractical, toy-like technology. Fun to look at, maybe, but impractical.

\n\n

Impossible tooling

\n\n

LSPs struggle significantly against this. Not only are symbols mismatched textually, there is not even a way to trace their origin programmatically. There are only a few reasonable LSPs for Ruby, none of which I found very good.

\n\n

In a sensible metaprogramming system you should generally provide some way to map parts of the generated code to where they originate—either in the source code of the generator, e.g. a macro, or the user call site where that generator is invoked. Take Rust’s macros for example. There is the concept of a span which specifically refers to a region of source code, not just a string. When you use a span in the expansion of a macro, language tooling can later trace the resulting definition to the original span.

\n\n

It would be very helpful, going back to my example, if not_published was somehow statically accessible and referred to the original location of the published symbol. It would at least allow go to definition functionality to some extent. But Ruby has no such capabilities. You can inspect certain properties of dynamically generated code, like Method#source_location, but this is hardly sufficient. The larger problem is that all such information is only available at runtime. There is often just no way of statically deducing what the meaning of your code is.

\n\n

Even Sorbet (a static type checker I’ll come back to later on) has a generator for type shims which resorts to simply loading the Rails application in development and inspecting pre-defined sets of classes and symbols and inferring their types, more or less intelligently. Don’t get me wrong, I find the efforts of Sorbet and its tooling commendable, given the inherent restrictions of the language they aim to support. But this is a mess.

\n\n

The most helpful LSP-like editor plugins for Rails I’ve seen were usually implemented for specific layers of the framework, with basically hardcoded rules for symbol generation.

\n\n

Some people recommended RubyMine to me. Supposedly it would have some superior LSP functionality. I’ve never used it, but I don’t believe it can be significantly better because of the inherent nature of these issues, and it’s a big piece of software that I don’t think should be required to comfortably use a programming language.

\n\n

Dynamic typing is expensive

\n\n

This is something I feel every less experienced engineer has to learn the hard way sooner or later. Dynamic typing makes sense so long as you can infer your runtime types from variable names and context alone. As soon as you are not the only person holding the entire codebase and domain context in your head, you just can’t be sure what types you’re dealing with anymore and end up spending hours debugging runtime type errors. It gets increasingly worse as boundaries arise between components/modules, with potentially separate teams working on either side.

\n\n

I guess you can also argue that it’s always a trade-off: You either get a lot of compile-time errors with static typing, or a lot of runtime errors with dynamic typing. But I don’t think anyone argues that the latter is somehow preferable in large production code.

\n\n

Sorbet is a good attempt at putting a band-aid on existing codebases in a gradual and non-invasive way. It’s quite early in development (at least up until a few months ago) and the type system makes some unfortunate trade-offs borrowed from TypeScript, which made me sad, but overall it’s worth checking out. As someone experienced with both statically typed languages and Ruby I had little to no issue gradually introducing Sorbet into a large production codebase. One thing I found it solves really nicely is missing nil checks. It also has reasonably powerful runtime validation (similar to pydantic), so it was a huge help in defining DTOs across component boundaries.

\n\n

Going forward

\n\n

Getting serious stuff done in this technology requires intense discipline, contrary to the somewhat naive belief that technologies with fewer compile-time checks allow building things faster. Yes, you might roll out an MVP with less code typed, but the time it takes you to develop it any further will grow exponentially.

\n\n

Fortunately, I think this perspective is increasingly common in the modern day. Again, Ruby’s glory days have probably passed a long time ago, together with other similar technologies. I think Python today usually has type hints and you will get reasonable static checks and not a lot of runtime macro voodoo.

\n\n

Were I to pick up a Ruby codebase today, I would be extremely mindful of the level of code style standards it employs, to make sure it at least tries not to make these issues worse.

", "summary": "Lessons Learned After 4+ Years of Ruby on Rails", "date_published": "2026-07-13T00:00:00+00:00", "date_modified": "2026-07-13T00:00:00+00:00", "author": { "name": "Michał Wawrzynowicz "}, "tags": []},{ "id": "https://michalwa.github.io/2026/07/10/designing-a-database", "url": "https://michalwa.github.io/2026/07/10/designing-a-database.html", "title": "Designing a Database for a Prolog-based PKM Application", "content_html": "

Designing a Database for a Prolog-based PKM Application

\n\n

\"factbook

\n\n

Introduction

\n\n

factbook is a minimalist PKM app I’ve been working on for the past few months as a hobby project. It’s written in Rust using Tauri and Solid.js for the UI. Its workflow resembles Zettelkasten—small, atomic entries and heavy use of tags which emerge organically. What makes it unique is that all organization logic is entirely delegated to a user-facing scripting layer built on top of Prolog.

\n\n

Prolog is a logic programming language. Aside from being 100% Turing-complete, logic problems and relational search are where it really shines. The interpreter is pretty much a first-order logic solver and has built-in concepts of choice points, backtracking, etc. The language also relies heavily on the concept of unification, which can be thought of as a form of pattern matching, which makes it really easy to express very complex nested relations within data structures. It has many similarities to the LISP family—although it doesn’t use S-expressions, its design very much follows the spirit of code as data.

\n\n

If you’re unfamiliar with logic programming and are open to exploring new, foreign paradigms of thinking I encourage you to investigate further. Prolog has defined a completely new perspective on many concepts in both programming and mathematics for me. I think people usually get introduced to Prolog in an academic setting, but I just stumbled upon it one day in my spare time and got hooked.

\n\n

The way factbook attempts to take advantage of this technology is by allowing users to tag their entries with arbitrary Prolog terms. In short, this means instead of simple tags like #book or #task, you can write @book([read(false), rating(3)]), meaning you can pretty much embed arbitrary data structures into your notes, which I think is pretty cool. Prolog’s minimalist syntax makes it quite clean and readable too, as opposed to using something obvious like JSON.

\n\n

The way you can then reason about these tags is by means of queries (views), which are made to look more or less like a subset of Prolog, giving you pretty much the entire language at your disposal, with some domain-specific/quality-of-life features added on top.

\n\n

I would often find myself using PKM/note-taking apps in elaborate, over-engineered ways. And sometimes they just weren’t enough or didn’t feel right, which is how I came up with the idea once I got more or less comfortable using Prolog. It just seemed like a fun project to work on potentially leading to an actual usable product, or at least usable by me :) I won’t pretend like the main reason I’m building this thing isn’t just because it’s fun to think about.

\n\n

I’m not aware of any similar attempts, although similar tools in general do exist. Most noteworthy probably being Emacs Org Mode, which I’m planning to study at some point.

\n\n

The problem

\n\n

Let me first show you an example of how the app is designed to work. Here’s what a journal in factbook might look like. Entries are numbered for later reference; in the actual app they are annotated with timestamps.

\n\n
0 | @todo(false) this is an uncompleted task\n1 | @todo(true) this is a completed task\n2 | this is a @todo(false) in the context of @work\n3 | this is a @thought where I want to @cite(\"Einstein\", 1905)\n4 | another @thought\n5 | some research @cite(\"Turing\", 1936)\n
\n\n

Now, say you want to list all uncompleted tasks. You would simply use the query: @todo(false). Want to see all tasks regardless of completion? Put an unbound variable as the argument: @todo(_). Of course, there’s also boolean operators: conjunction (,) and disjunction (;), so you can say things like @todo(false); @thought, @cite(_, _) (uncompleted tasks or thoughts which cite something).

\n\n

There’s also other predicates which don’t refer to tags. For instance, you can reason about the creation times of entries (created(_)); or execute completely arbitrary Prolog code ({ ... }). This naturally includes accessing the file system or making web requests, not that you should necessarily do those things.

\n\n

Evaluating these kinds of queries in Prolog on its own is trivial. However, it requires that the associations between entries and their tags are available to the Prolog runtime. This is where the engineering challenge begins. How can we store this data in a way that is maintainable, efficient to mutate, and available to the Prolog runtime?

\n\n

The easy solution

\n\n

Prolog maintains a database which you normally populate with a program ahead of time and subsequently query (or evaluate goals). Let’s see what our example entry database could look like written as a Prolog program:

\n\n
entry_tag(0, todo(false)).\nentry_tag(1, todo(true)).\nentry_tag(2, todo(false)).\nentry_tag(2, work).\nentry_tag(3, thought).\nentry_tag(3, cite(\"Einstein\", 1905)).\nentry_tag(4, thought).\nentry_tag(5, cite(\"Turing\", 1936)).\n
\n\n

I’m making the rather obvious assumption here that we’re interested in storing parsed tags and not entry content to avoid having to parse each entry during search. I leave storage of entry content as a separate question for now, though it would definitely be nice to arrive at a solution which also accounts for it.

\n\n

The above list of facts defines the predicate entry_tag/2 (standard notation, /2 indicates arity) which associates an entry ID with a tag included in the entry. To then retrieve IDs of entries containing the todo/1 tag, for example, we could use the following Prolog query: ?- entry_tag(E, todo(_)).

\n\n

But say we change the content of entry 0 from “@todo(false) this is an uncompleted task” to “@todo(true) this is a completed task”. How can we update the Prolog database accordingly? Nuking the entire runtime and initializing a new one with a new state after every change won’t do. So what else can we do?

\n\n

Well, it turns out you can declare facts and rules at “query time” using asserta/1 and assertz/1. These are special built-in predicates, which you can query just like other predicates, including as part of rules, but have the side effects of either prepending or appending facts or rules to the database. There are also a bunch of related predicates for retracting clauses from the database.

\n\n

Going back to our example.

\n\n

To be safe we would probably need to first retract all facts about that entry:

\n\n
retract(entry_tag(0, _)).\n
\n\n

And subsequently assert the facts corresponding to each of the new tags:

\n\n
assertz(entry_tag(0, todo(true))).\n
\n\n

If the entry got deleted as a whole, we would only do the retraction.

\n\n

At startup, we would of course have to parse all entries, serialize the ID-tag pairs into Prolog clauses and pass them to the interpreter.

\n\n

This might seem like a perfect solution at first glance and, to be fair, I have not honestly tested this and verified its performance. It could turn out that for small sets of entries it’s completely viable. However, I immediately got a strong gut feeling that this would not be the way to go.

\n\n

In a professional setting, I would probably go through the effort of actual prototyping to have concrete measurements to base my judgment on. In my personal project I get to skip that part.

\n\n

Let me try to explain why I felt this way:

\n\n

Having to manage state through the Prolog interpreter would be cumbersome. All mutations would have to go through this layer instead of being written in plain Rust, or even worse, Prolog would have to be kept in sync with other external data structures.

\n\n

In any case, it’s questionable architecturally. Relying on the Prolog database gives limited to no control over the way data is stored. It wouldn’t be possible to take advantage of convenient Rust crates / data structures to implement the storage and any potential improvements or additions would be dependent on the specifics of Prolog or even its particular implementation.

\n\n

I make actual performance judgments warily, having skipped actual benchmarking, but I reckon the universal nature of the dynamic database would ultimately prove worse than a custom native implementation. Prolog interpreters do provide certain ways to improve performance from the level of user code, but still possess certain inherent constraints.

\n\n

Setup

\n\n

The way you interface with the Prolog interpreter is split into two aspects:

\n\n

Constructing terms: This is done with functions like PL_put_atom or PL_put_functor, which you call “bottom-up” to construct your term trees. In my Rust wrapper around SWI-Prolog I have a macro which allows me to do this more conveniently. You can also simply delegate parsing to the interpreter using PL_put_term_from_chars, with some limitations. The one crucial use of this is for constructing the query term (goal).

\n\n

Calling Rust from Prolog: This is where the magic happens. You can register foreign predicates in the Prolog runtime pointing to native implementations that will be called to obtain solutions. The implementations are free to emulate all of the properties of regular predicates.

\n\n

There are generally several modes of predicates, the two which are relevant here being semi-deterministic and non-deterministic. The former are allowed either to fail or to succeed exactly once (producing a single solution). The latter may succeed an arbitrary number of times, producing alternative solutions. Our earlier definition of entry_tag/2 is an example of a non-deterministic predicate, since for certain arguments (even fully instantiated, as entries may contain duplicate tags) it may yield more than one solution.

\n\n

In my wrapper, I have two traits describing this (simplified):

\n\n
trait Semidet {\n    fn call(args: &[Term]) -> bool;\n}\n\ntrait Nondet {\n    fn init() -> Self;\n    fn next(&mut self, args: &[Term]) -> bool;\n}\n
\n\n

As you can see, non-deterministic predicates are allowed to construct a state and mutate it upon each invocation during search.

\n\n

Terms, on the other hand, may contain arbitrary blobs of bytes, meaning we can actually embed references to some native state into the goal term and pass it down to our foreign predicate implementation. The wrapper defines a bunch of blob types which allow doing this with proper Rust borrow checking.

\n\n

The predicate implementation may then construct its internal state which can hold those references and allow each subsequent invocation to read our native application state.

\n\n

Altogether, this lets us construct the core infrastructure that will allow us to implement any kind of search natively in Rust and make it available to Prolog.

\n\n

\"architecture

\n\n

So far so good

\n\n

Okay, but we are left with actually implementing the storage and search.

\n\n

Let’s first assume our native predicate will have a similar signature to what we initially sketched out, meaning: entry_tag(Id, Tag). Since we know we’ll have to pass external context, let’s also include that as an argument: entry_tag(Ctx, Id, Tag). This context will include a reference to the actual storage of entires, as well as any indexes or caches we decide to maintain for support.

\n\n

Using my Rust wrapper crate, you can specify this as follows:

\n\n
#[derive(ScopedBlobData)]\nstruct Context<'a>(&'a /* some internal storage type */);\n\n#[predicate(entry_tag(ctx, id, tag) nondet)]\nstruct EntryTag { /* ... */ }\n\nimpl Nondet for EntryTag {\n    /* ... */\n}\n
\n\n

When the user submits a query, we want to:

\n
    \n
  1. Wrap references to application state in a Context blob.
    2. \n
  2. Construct the query term (goal) with the following arguments:\n
      \n
    • the newly constructed Context blob,
      • \n
    • the user’s query,
      • \n
    • an unbound variable which will be unified with matching entry IDs.
      • \n
    \n
    3. \n
  3. Evaluate the query and collect the resulting entry IDs.
    4. \n
\n\n

There is still the question of translating the custom view language into a Prolog query. In factbook this is implemented on the Prolog side as a regular predicate taking the view as an argument and invoking the foreign predicate when necessary.

\n\n

Let’s now think about some example invocations of the predicate and what they should return:

\n\n
entry_tag(_, E, thought). % context blob is omitted here\n
\n\n

This should yield solutions for E where the entry contains the tag @thought. In our example, that would be E = 3 and E = 4.

\n\n

Given a list of entries and tags, you can imagine having a simple inverted index by tag names to efficiently traverse entries sharing the same tag. This gives us our first clue for what the implementation should look like.

\n\n
struct Database {\n    entries: BTreeMap<EntryId, Entry>,\n    tags: Vec<(EntryId, Tag, TagData)>,\n    tag_indices: BTreeMap<Tag, Vec<usize>>,\n}\n\n#[derive(ScopedBlobData)]\nstruct Context<'a>(&'a Database);\n\n#[predicate(entry_tag(ctx, id, tag) nondet)]\nstruct EntryTag {\n    iter: Option<Box<dyn Iterator<Item = (EntryId, TagData)>>>,\n}\n\nimpl Nondet for EntryTag {\n    fn init() -> Self {\n        Self { iter: None }\n    }\n\n    fn call(&mut self, [ctx, id, tag]: &[Term]) -> bool {\n        // extract `Context` from `ctx`\n\n        if self.iter.is_none() {\n            // initialize iterator based on `tag`\n        }\n\n        for (entry, tag) in self.iter.as_mut().unwrap() {\n            if /* unify with `id` and `tag` */ {\n                return true;\n            }\n        }\n\n        false\n    }\n}\n
\n\n

Note that because we allow arbitrary data to be used inside tags, including strings, numbers, and the like, we probably want a way to construct keys for these terms which represent their general structure, rather than concrete values. This is represented by the Tag type in the snippet above, as opposed to TagData which would store the actual concrete value of a tag.

\n\n

In cases where the tag is a compound term, we can simply use the functor as the index:

\n\n
entry_tag(_, E, todo(_)). % search by `todo/1`\n
\n\n

We could also choose to index based on a predetermined number of initial arguments, or allow users to choose their own indexing strategies based on the intended usage of the tags, etc.

\n\n

So far so good, but imagine you have a query even slightly more complex than a single tag predicate:

\n\n
@thought, @cite(_, _)\n
\n\n

The predicate invocation would look like this:

\n\n
entry_tag(C, E, thought), entry_tag(C, E, cite(_, _)).\n
\n\n

Without any additional optimizations, we suddenly arrive at quadratic time complexity. For each solution yielded by the first invocation of entry_tag, Prolog will invoke the second one and the implementation will in turn attempt to unify each of its solutions with the solution yielded from the first invocation.

\n\n

Here’s a visualization of this using our initial example journal:

\n\n
?- entry_tag(C, E, thought).\n   index search yields `E = 3` and `E = 4`\n     ?- entry_tag(C, 3, cite(_, _)).\n        index search yields `E = 3` and `E = 5`\n          ?- 3 = 3. true\n          ?- 3 = 5. false\n     ?- entry_tag(C, 4, cite(_, _)).\n        index search yields `E = 3` and `E = 5`\n          ?- 4 = 3. false\n          ?- 4 = 5. false\n
\n\n

In this example 4 cases were tested only for 1 to result in a valid solution: E = 3

\n\n

An easy first optimization is to traverse entries instead of tags when possible. We can simply detect whether entry_tag is called with an already unified ID argument, and then choose to iterate over other tags in the same entry instead of all entries matching the tag. This should be much better, because entries will realistically contain much fewer tags than there will be entries matching that tag.

\n\n
impl Nondet for EntryTag {\n    fn call(&mut self, [ctx, id, tag]: &[Term]) -> bool {\n        // ...\n\n        if self.iter.is_none() {\n            if let Some(id) = id.get::<EntryId>() {\n                // initialize iterator based on `id`\n            } else {\n                // initialize iterator based on `tag`\n            }\n        }\n\n        // ...\n    }\n}\n
\n\n

The search should then look something like this:

\n\n
?- entry_tag(C, E, thought).\n   index search yields `E = 3` and `E = 4`\n     ?- entry_tag(C, 3, cite(_, _)).\n        entry contains tags `thought` and `cite(\"Einstein\", 1905)`\n          ?- cite(_, _) = thought. false\n          ?- cite(_, _) = cite(\"Einstein\", 1905). true\n     ?- entry_tag(C, 4, cite(_, _))\n        entry contains tags `thought`\n          ?- cite(_, _) = thought. false\n
\n\n

So the index search helps us narrow down the initial search space, but then we fall back to linear scans assuming realistically smaller data sets.

\n\n

This is actually the way the predicate is designed and implemented at the time of writing this article. It strikes a good balance between implementation simplicity (if you can call it that) and performance. It hasn’t been stress-tested against large datasets nor properly benchmarked and this is something I’m not planning to do anytime soon, because I don’t expect the app to be used heavily by anyone in the near future :) Most of what I talk about here are ahead-of-time optimizations, you could maybe argue premature. Still, they are not arbitrary, as I try to think what kind of workloads can be reasonably expected given the application’s design.

\n\n

Taking it further

\n\n

The solution is of course still suboptimal for certain imaginable use cases. Namely, for a conjunction query like in the example above, the two tags may only share a small subset of associated entries, in which case the first specified tag will determine the time it takes to find them, performing a lot of wasted iterations. Ideally we would want to optimize finding solutions for arbitrary boolean expressions.

\n\n

This is obviously the opening of a huge rabbit hole, one I will surely be tempted to explore in the near future.

", "summary": "Designing a Database for a Prolog-based PKM Application", "date_published": "2026-07-10T00:00:00+00:00", "date_modified": "2026-07-10T00:00:00+00:00", "author": { "name": "Michał Wawrzynowicz "}, "tags": []}] }