# Proposal for Moving Forward for Fast DB Access

**URL:** <https://gramps.discourse.group/t/proposal-for-moving-forward-for-fast-db-access/9179>\
**Category:** Development\
**Tags:** performance\
**Created:** [February 28, 2026, 7:24pm UTC](https://gramps.discourse.group/t/proposal-for-moving-forward-for-fast-db-access/9179 "2026-02-28T19:24:57Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\
**Post date:** [February 28, 2026, 7:24pm UTC](https://gramps.discourse.group/t/proposal-for-moving-forward-for-fast-db-access/9179/1 "2026-02-28T19:24:57Z")

</div>

I have a new proposal about how to move forward in allowing filters to be SQL optimizable.

I developed [a method in Dec 2024 that allowed Python syntax to be converted into SQL](https://github.com/gramps-project/gramps/pull/2151). But this is a bit complicated, and there aren’t very many people in the Gramps development community today that can appropriately review it. And it is opinionated in its approach. One might argue that the syntax shouldn’t be the one and only for core Gramps, and I wouldn’t argue. (There are lots of options for Object-Relational Mappers (ORM) for Python, like SQLAlchemy).

My proposal: create a well-defined method of allowing database plugins to override filter implementations. This keeps Gramps operating exactly as it is, but also allows a plugin to be able to use whatever method to implement direct SQL (or other backend) commands.

I’ll move my `select_from_table` method (from above) to a plugin. And people can decide to use that or not, and development can happen outside the core Gramps development release time line.

I’ve created a PR (work in progress, but almost done): [Add register\_override API so DB backends can plug in optimized implementations](https://github.com/gramps-project/gramps/pull/2177). This has the bare minimum to allow such plugins to be developed. If a database has registered an Rule override, then it will be used instead. This can also take advantage of the Filter Optimizer added in Gramps 6.0.

I look forward to getting the Gramps 6.1 PRs reviewed and merged. Questions and comments of course welcomed!

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/gramps/original/1X/2ac1e712b7adf612e31ca08a55419f4cf37c0158.png) [@system](https://gramps.discourse.group/u/system)\
**Post date:** [March 30, 2026, 7:25pm UTC](https://gramps.discourse.group/t/proposal-for-moving-forward-for-fast-db-access/9179/2 "2026-03-30T19:25:41Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

---

<div class="post-metadata">

**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\
**Post date:** [June 3, 2026, 3:48pm UTC](https://gramps.discourse.group/t/proposal-for-moving-forward-for-fast-db-access/9179/3 "2026-06-03T15:48:33Z")

</div>

I’ve created a discussion post for developers on how the filter optimizer works:

> **[Filter Optimization: \`selected\_handles\` · gramps-project gramps · Discussion...](https://github.com/gramps-project/gramps/discussions/2350)**
>
> This document explains the filter optimization system built into Gramps 6.0 and describes how developers can extend it in new or existing filter rules. Currently this isn't very well documented, an...

Will need to figure out a place for this to live.