# DB PostgreSQL support

**URL:** <https://discuss.write.as/t/db-postgresql-support/184>\
**Category:** Feature requests\
**Tags:** writefreely\
**Created:** [November 29, 2018, 3:37am UTC](https://discuss.write.as/t/db-postgresql-support/184 "2018-11-29T03:37:45Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![ashleyhull-versent](https://discuss.write.as/user_avatar/discuss.write.as/ashleyhull-versent/32/463_2.png) [@ashleyhull-versent](https://discuss.write.as/u/ashleyhull-versent)\
**Post date:** [November 29, 2018, 3:37am UTC](https://discuss.write.as/t/db-postgresql-support/184/1 "2018-11-29T03:37:45Z")

</div>

I’m running PostgreSQL for my Mastodon instance, and I’d like to use the same DB for writely to save resources and keep costs down.

Any chance of supporting a DB abstraction to allow both maria and PostgreSQL?

---

<div class="post-metadata">

**Author:** ![matt](https://discuss.write.as/user_avatar/discuss.write.as/matt/32/2760_2.png) [@matt](https://discuss.write.as/u/matt)\
**Post date:** [November 30, 2018, 7:50pm UTC](https://discuss.write.as/t/db-postgresql-support/184/2 "2018-11-30T19:50:13Z")

</div>

The next (and likely final) database engine the team is going to build support for [will be SQLite](https://phabricator.write.as/T529). Our primary goal is to make WriteFreely installation as easy as possible, so that’ll help everyone avoid these relatively heavy engines and keep everything self-contained. However, if anyone in the community wants to contribute the changes necessary for PostgreSQL support – and especially if they want to help maintain it – we’ll gladly welcome that.

With SQLite support we’ll also add test cases to ensure database functions work consistently across different storage engines, etc., so those changes should make supporting other backends (like PostgreSQL) much easier.

_(Note: we’ll continue the [previous GitHub discussion](https://github.com/writeas/writefreely/issues/20) about this on this thread.)_

---

<div class="post-metadata">

**Author:** ![BenOvermyer](https://discuss.write.as/user_avatar/discuss.write.as/benovermyer/32/43_2.png) [@BenOvermyer](https://discuss.write.as/u/BenOvermyer)\
**Post date:** [November 30, 2018, 8:35pm UTC](https://discuss.write.as/t/db-postgresql-support/184/3 "2018-11-30T20:35:57Z")

</div>

I’ll be working on the SQLite support this weekend. While I’m doing that work, I’ll also be noting things that might need to be changed to work with PostgreSQL.

---

<div class="post-metadata">

**Author:** ![matt](https://discuss.write.as/user_avatar/discuss.write.as/matt/32/2760_2.png) [@matt](https://discuss.write.as/u/matt)\
**Post date:** [November 30, 2018, 8:45pm UTC](https://discuss.write.as/t/db-postgresql-support/184/4 "2018-11-30T20:45:21Z")

</div>

Awesome, that’ll help a lot 👍

---

<div class="post-metadata">

**Author:** ![f0x](https://discuss.write.as/user_avatar/discuss.write.as/f0x/32/175_2.png) [@f0x](https://discuss.write.as/u/f0x)\
**Post date:** [December 6, 2018, 12:18am UTC](https://discuss.write.as/t/db-postgresql-support/184/5 "2018-12-06T00:18:12Z")

</div>

+1 for wanting PostgreSQL support, other federated software uses it as well (Mastodon, Pleroma, Matrix) so it’s nice to run them all in the same db server

---

<div class="post-metadata">

**Author:** ![robw](https://discuss.write.as/user_avatar/discuss.write.as/robw/32/274_2.png) [@robw](https://discuss.write.as/u/robw)\
**Post date:** [May 24, 2019, 3:15pm UTC](https://discuss.write.as/t/db-postgresql-support/184/6 "2019-05-24T15:15:23Z")

</div>

Is anybody else working on this right now?

Would people be happy to see Postgres support shoe-horned into the existing `database.go`, or would some other approach be needed?

---

<div class="post-metadata">

**Author:** ![ashleyhull-versent](https://discuss.write.as/user_avatar/discuss.write.as/ashleyhull-versent/32/463_2.png) [@ashleyhull-versent](https://discuss.write.as/u/ashleyhull-versent)\
**Post date:** [February 10, 2020, 6:50am UTC](https://discuss.write.as/t/db-postgresql-support/184/7 "2020-02-10T06:50:54Z")

</div>

Bump. I’m all for SQLite as a primary DB if that’s the goal…

but mastodon/pixelfed/funkwhale and others are all on postgres… so I’m keen on hosting less moving parts

---

<div class="post-metadata">

**Author:** ![matt](https://discuss.write.as/user_avatar/discuss.write.as/matt/32/2760_2.png) [@matt](https://discuss.write.as/u/matt)\
**Post date:** [February 10, 2020, 2:06pm UTC](https://discuss.write.as/t/db-postgresql-support/184/8 "2020-02-10T14:06:30Z")

</div>

We’ll be happy to support Postgres as well – we just doesn’t have the bandwidth for all that extra maintenance work without dedicated funding or development help from the community.

MySQL is our priority since we use it in production on [Write.as](https://write.as), and SQLite ensures WriteFreely is easy to deploy, a primary product goal for us. So we just need some extra help for other DB engines.

@robw Adding it into `database.go` should work just fine! Everything else is in there already.

---

<div class="post-metadata">

**Author:** ![ltdk](https://discuss.write.as/letter_avatar_proxy/v4/letter/l/8491ac/32.png) [@ltdk](https://discuss.write.as/u/ltdk)\
**Post date:** [March 7, 2020, 12:47am UTC](https://discuss.write.as/t/db-postgresql-support/184/9 "2020-03-07T00:47:15Z")

</div>

I’d also be interested in PostgreSQL support, as I run a small server that uses PostgreSQL-only software and would rather share a single database system. That said, I 100% understand that you don’t have the bandwidth to implement it without external help, and I definitely feel that MySQL is more appropriate for larger-scale applications.

---

<div class="post-metadata">

**Author:** ![tcyrus](https://discuss.write.as/user_avatar/discuss.write.as/tcyrus/32/517_2.png) [@tcyrus](https://discuss.write.as/u/tcyrus)\
**Post date:** [April 9, 2020, 8:44pm UTC](https://discuss.write.as/t/db-postgresql-support/184/10 "2020-04-09T20:44:43Z")

</div>

This task might be easier if WriteFreely used something like [`xorm`](https://gitea.com/xorm/xorm).

---

<div class="post-metadata">

**Author:** ![gytisrepecka](https://discuss.write.as/user_avatar/discuss.write.as/gytisrepecka/32/233_2.png) [@gytisrepecka](https://discuss.write.as/u/gytisrepecka)\
**Post date:** [April 10, 2020, 8:29am UTC](https://discuss.write.as/t/db-postgresql-support/184/11 "2020-04-10T08:29:09Z")

</div>

On one hand, database abstraction layer would be nice and open new possibilities to introduce different engines. On the other hand, even most common relational databases have certain differences so it might add extra overhead to implement.

SQLite, in my view, is applicable only to tiny implementations or apps (Android uses it as app data backend). Main issue that doesn’t allow me to treat SQLite seriously is dynamic/weak datatypes. Therefore any decent relational database is much better for integrity and scalability.

So official support for at least one modern RDBMS is a must. When it comes to web apps, MySQL/MariaDB is so popular due to easier maintenance (my subjective opinion), but as other fediverse servers like Mastodon, PeerTube, etc. have chosen PostgreSQL, it might be useful to consider.

I myself haven’t gone deep into database model used by WriteFreely at the moment, but I might give some suggestions bit later.

---

<div class="post-metadata">

**Author:** ![matt](https://discuss.write.as/user_avatar/discuss.write.as/matt/32/2760_2.png) [@matt](https://discuss.write.as/u/matt)\
**Post date:** [April 10, 2020, 8:57pm UTC](https://discuss.write.as/t/db-postgresql-support/184/12 "2020-04-10T20:57:17Z")

</div>

Yeah, I always prefer less abstraction, especially with critical layers of the app. The plain query system is a bit messy, but it works correctly and is easy to debug. Abstraction creates more work when things go wrong, and a new database driver on top will only multiply the effort needed.

For anyone interested in helping us move this forward, I just wrote a basic walkthrough of what’s needed: [PostgreSQL support](https://discuss.write.as/t/postgresql-support/1260). Please feel free to give it a shot and let us know how it goes!
