Developing FINNoco and why we at FINN love using NocoDB
Tags: finn, nocodb, finnoco, postgres
Published: 2022-10-26 15:12:25

At FINN we’re big users of open source Airtable alternative [NocoDB](https://www.nocodb.com/). We’ve even developed our own version, which we’re calling ‘FINNoco’. So how did our journey with NocoDB all get started, and where are we at now?


## How FINN got started with NocoDB

Let’s go back to the gloomy days of July 2021. At that time, at FINN we still had everything on Airtable. But we were growing so fast, and so we ran into many, many limitations. There were API limitations. Everything was super slow. Even the UI was slow sometimes. On some occasions, Airtable would just be unresponsive for ages. These problems made us realise we had to look for a solution. We had to move away from Airtable. But how? And where to?

While I wasn’t part of the conversation at the time, I know we considered a range of alternatives—including [Baserow](https://baserow.io), which is also a no-similar to Airtable. But when one of my colleagues, Alex Yasnogor, discovered NocoDB, we realised we had what looked like a promising alternative.

At this point, NocoDB itself had been developed only very recently. Initially, it started as a pet project of Naveen Rudrappa, called ‘xmysql’, which would create APIs on a MySQL database. When Naveen realised that people got interested, he added the UI layer. And then slowly, xmysql became NocoDB. I guess jumping in with a new project so early could have brought some uncertainties. But given our pain points with Airtable, we were ready to take the plunge.

What was crucial for us is that with NocoDB, you can connect your own SQL database and make it into a no-code or low-code database. Yes, we wanted to have a user interface (UI) layer. For example, with no-code or low-code tools, such as [Make](https://www.make.com) (formerly known as ‘Integromat’) and [Retool](https://retool.com/), we will connect things through NocoDB. But at the same time, we also wanted to have the freedom to connect directly to our Postgres database, which we usually do in services and microservices. Such a setup works well for non-technical people, who get the UI layer. And the technical team has a proper SQL database, so developers are also happy too. It gives us flexibility. 


## How FINN currently uses NocoDB

Our current setup with NocoDB differs for our operations in Germany and those in the USA. For Germany, because we started with Airtable, today we still have both Airtable and NocoDB as data sources. So we write data to Airtable, sync that data in Postgres and NocoDB, and then we're reading the data from NocoDB. All of this mainly to reduce the APIs’ usage of Airtable. We currently have two major migration projects ongoing to move away from Airtable—which we’ve named ‘Green Dragon’ and ‘Blue Dragon’, because they’re such huge beasts to tackle—in which we use Postgres as the data source and have NocoDB on top of it, just for reading the data.

In the USA, however, we could make a fresh start. Because we'd learnt about Airtable’s limitations, we decided not to use it in the US at all. Instead, in the US we've started using NocoDB right from the start, and NocoDB is getting used as the only data source. Here we’re using the NocoDB UI to read, add, and manipulate the data. And we’re also using it directly with our APIs.

The current situation of using both Airtable and NocoDB will likely still continue for another year or so, as we still have some important projects on Airtable. But once we finish this whole transition to the new architecture, we will stop using Airtable completely.


## FINNoco and contributing back to NocoDB

Another nice thing about going all-in with NocoDB, is that we’ve now developed our own version, called ‘FINNoco’ (a name suggested by our CTO, Andreas Wixler). Initially, I personally wasn’t much involved with this, but when the developer who previously worked on NocoDB left, I had the opportunity to take it over. NocoDB is open source, so this is a great way to get some wider recognition for your work as a developer.

Our process in developing FINNoco is that we work on the things we need to, and when there are important fixes or improvements, we’ll contribute those back to the source NocoDB. This is beneficial all round: we at FINN get recognition for our contributions, and the community can benefit from our work.


![A new release of FINNoco](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7w6ammusl1ilikjmscc8.png)
<figcaption>A new release of FINNoco</figcaption>


FINN currently is among the biggest users of NocoDB. And precisely for that reason, we also regularly find some improvements or bugs that the NocoDB core team may miss. Contributing back fixes to the source NocoDB project improves the product a lot. The types of contributions we make vary. Often it’s bug fixes or improvements, but sometimes we also contribute features. For example, there is an attachment column in NocoDB, where you can upload a file. In source NocoDB, the file is always public. But in FINNoco, you can mark the file as private as well, for security reasons. This is crucial when you’re dealing with confidential information. We’re planning to contribute this feature back to the source NocoDB soon.

As a result of FINN’s extensive use of NocoDB, we have a close relationship with the founder and the core team too. We frequently call, and have a joint Slack channel where we can talk directly. Plus, the NocoDB team also seeks advice from our side. For instance, they're currently planning to roll out an enterprise version. So then they ask us, for example, what hardware we have at FINN for FINNoco, so that they can baseline their enterprise and what pricing they apply.


## Future visions for the FINN-NocoDB connection

NocoDB is definitely going to be part of our future operations. In terms of FINN’s plans, we're actually already moving toward our desired picture:

- **Rapid prototyping** – We want to use NocoDB wherever we do rapid prototyping. For example, if tomorrow we decide to introduce our car subscription model in another country, then NocoDB would be the go-to tool again, as it was for us when we launched in the USA. It can help us build things fast.

- **NocoDB APIs** – We also want to use more of NocoDB’s APIs, and use the UI only for viewing the data, rather than for data manipulation. In the future, we would ideally use interfaces such as Retool, or some dedicated services, to do the data manipulation. Right now, the APIs available from NocoDB are simple CRUD (create, read, update, and delete) APIs. But there are also some APIs where you can count the number of rows, or which can help you read related table data. We’d like to use more of those.

- **Release FINN NocoDB app** – At FINN, we have developed our own private NocoDB app for use in Make, which we will be releasing for public use in a few weeks. That’s another contribution to the community that we’re very much looking forward to making.

A further change I would like to see is for people to use NocoDB APIs instead of connecting directly to a Postgres database. When current limitations to these APIs have been removed, then I would expect our use of NocoDB to grow even further.