A Belgian software house that starts with the data
HORIZONIS HOLDINGS BV is registered in Belgium under number 0973773102. We develop database management systems and publish engineering guidance on relational platforms and administration tooling. The company is deliberately small, technical, and based in Brussels.
The company
We are a software house, not a consultancy that exists mainly to staff projects with borrowed people. The distinction matters because it shapes what we are good at. Our default instinct on a new problem is to build a component, a tool or an internal system rather than to write a report and hand it over.
That said, a lot of database work genuinely is assessment and design before anything gets built. We do both, and we are clear about which one a given engagement is. A schema review is not a product. A migration is not a strategy document.
The engineering team
The team is small enough that everyone works on production systems. There is no layer of people whose job is only to talk about the work. When a client calls +3225244847 with an incident, they reach someone who knows the schema in question.
Belgian database work has a particular flavour. Dutch-speaking colleagues, French-speaking colleagues, and English as the usual common language of technical documentation. European data protection rules that apply on every project whether or not a client asks about them. We have built our habits around that environment rather than importing practices from elsewhere.
A team this size also changes the way a project is scoped. There is no handoff between an analyst who interviews the client and an engineer who later discovers the constraints that were not mentioned, because the same person sits in both conversations. Documentation is written by the people who will maintain the system, and internal review is a walk to a colleague's desk rather than a committee.
Where we sit
- Legal name
- HORIZONIS HOLDINGS BV
- Registration
- 0973773102
- Based in
- Brussels, Belgium
- Ways to reach us
- Contact the team
The relational model
Where most important data still lives
The relational model has been declared obsolete roughly once a decade since the 1980s, and it is still where most of the world's important data lives. PostgreSQL, MySQL, SQL Server and IBM Db2 between them run a staggering share of the systems that keep organisations operating. We take that as a reason to go deep rather than to chase whatever is new this year.
Going deep means caring about things that are unglamorous. Index design. Transaction isolation levels and what they actually mean under concurrent load. Backup schedules that have been tested by restoring, not just by looking at the job history. Query plans that get read and understood. None of this is exciting, and all of it is where most database problems originate.
Principles we hold
Four positions we do not move on
-
One
The database is part of the architecture, not a storage detail.
Schema decisions shape how fast a system can move for years. Treating the database as a place to put objects after the application design is finished is how a good product gets a slow decade.
-
Two
An administration tool should show you what is true, not what is convenient.
A dashboard that hides a growing table or a lock waiting behind a query is a dashboard that costs money. Bad news is more useful than a reassuring summary.
-
Three
Documentation written for visitors beats documentation written to impress.
A document someone can follow on a bad day is worth more than a formal one nobody opens. We write down what actually works, in the order it gets done.
-
Four
If a tool is bad at something, say so.
That applies to tools we use daily. pgAdmin is the official PostgreSQL administration platform and we rely on it, and it has rough edges. SQL Server Management Studio is the standard companion to SQL Server and it is Windows-bound. MySQL Workbench is a solid unified visual tool for MySQL, and it is not a general-purpose cross-platform client. Stating that is more useful than pretending otherwise.
Client engagements
Written before code, unflattering where that is accurate
Every project gets a written technical picture before code is written. That picture covers what exists, what is at risk, and what a realistic sequence of changes looks like. A client who is told their backup strategy has never been tested is better served than one who is told everything looks fine.
| What the picture holds | Why it goes in writing | What you get back |
|---|---|---|
| The current estate | Informal systems drift quietly. Writing down what runs where is the first honest step. | A short inventory you can hand to a colleague |
| Where the risk sits | Untested backups, a growing table, a query plan nobody has read. Named, not implied. | A ranked list, worst first |
| Personal data handling | Which fields exist, where copies live, retention, and who can query them belongs in design, not retrofit. | A field-level map for the GDPR questions you already answer |
| A realistic sequence of changes | Steps ordered so each one can ship without breaking the next. | A short roadmap you can start on or stop cleanly |
GDPR-aware data handling is not a separate workstream for us; it is part of how a database project is scoped. Retrofitting it later is more expensive and less effective.
Where we sit in the Belgian market
Belgium has a dense mix of small and mid-sized organisations running serious database estates. A company with seventy employees can easily have three engines in production and nobody who considers database administration their full-time role. That is the typical shape of the problem we are asked to help with.
The work usually starts as one question from whoever owns the application — a slow report, a migration nobody volunteered for, a backup job that has been failing quietly. From there, the estate builds its own picture of what else is worth doing.
Where the fit is weakest
We are not the right fit for every database need. Very large enterprise programmes with their own architecture functions usually have the internal capability already. Greenfield startups that will not touch a schema for a year do not need us yet. The fit is strongest when a working system has grown past what informal management can hold.
If you are not sure which side you are on, that is a reasonable question to bring to a first call. A short conversation usually settles it faster than a proposal.
Publishing as part of the job
We write it down, including the limits
The Insights section of this site is not content marketing bolted onto a software company. Writing down what we learn is how the team keeps its own understanding sharp, and it turns out to be useful to other people doing similar work. Articles cover relational platforms, cross-platform SQL tooling, open-source SQL clients and cloud-native database operations.
- Relational platforms Comparisons that say what each engine is good at and where each is awkward, rather than pretending one wins outright.
- Cross-platform SQL tooling Notes from running the same schema work across more than one client, and the habits that only fit one platform at a time.
- Open-source SQL clients What a free client does well, and the places where the trade-off still costs a working afternoon.
- Cloud-native database operations How tools such as CloudNativePG change PostgreSQL operations on Kubernetes — without pretending Kubernetes is simple.
We write the same way we talk to clients: concrete, with the limitations included.
What we build
Four layers of the same rack, built by one team
Schema
Design and review
Table and index design, constraint choices, migration paths that can be rolled back. We say when a change is safe and when it needs a staging window.
Query
Plans and performance
Slow queries get read, not guessed at. We look at plans, isolation levels under load, and where an application pattern is quietly defeating an index.
Backup
Restores you have tested
A backup job that reports success is not evidence. Restore drills, retention rules and where a copy of personal data actually lives all belong in the same document.
Ops
Day-to-day operation
Monitoring that surfaces the problems worth waking up for, access rules that hold, and a short runbook the person on call can actually follow at 3am.
Where a layer needs a piece of tooling that does not exist yet, we build it rather than assemble a workaround. That is often how an internal system becomes part of the product.
Getting in touch
The address and phone number are the same ones that appear in the footer and on the contact page. Company name HORIZONIS HOLDINGS BV, registration number 0973773102, based in Brussels.
Nothing about the business is hidden behind a form, though there is one if you prefer it.
Avenue Louise 143
1050 Brussels, Belgium
Monday to Friday, 9:00 AM – 6:00 PM
Three ways to go on from here
-
See what we build
The services HORIZONIS HOLDINGS BV takes on, from a schema review through a full relational platform migration.
-
Read how we run projects
The written technical picture, the phases we work in, and what a client is asked to prepare before we start.
-
Contact the team
A first call with the people who do the work, not a sales layer. Bring the system, the incident, or the question you cannot answer.
If you have already read something useful in the Insights section and want to test it against your own estate, that is also a good reason to write.