DEV Community

wiki.js on YugabyteDB

I've asked on LinkedIn which PostgreSQL application you use so that I can check that it works on Yugabyte. Please, continue to answer. To start let's try with Wiki.js, open source wiki software storing into a PostgreSQL database.

From the docker compose file in the documentation (Using Docker Compose) I changed the PostgreSQL database to YugabyteDB:

  • changed image: postgres:11-alpine to yugabytedb/yugabyte:latest
  • forward port 15433, the YugabyteDB UI, and 7000, the cluster console
  • changed POSTGRES_DB, POSTGRES_PASSWORD and POSTGRES_USER environnement variables to YSQL_DB, YSQL_PASSWORD and YSQL_USER
  • added command: yugabyted start --listen 0.0.0.0 --background=false
  • changed the volume to /root/var/data the default data dir
  • in the application, changed DB_PORT: 5432 to DB_PORT: 5433

Here is my docker-compose-yaml:

version: "3"
services:

  db:
    image: yugabytedb/yugabyte:latest
    ports:
      - "15433:15433"
      - "7000:7000"
    environment:
      YSQL_DB: wiki
      YSQL_PASSWORD: wikijsrocks
      YSQL_USER: wikijs
    restart: unless-stopped
    volumes:
      - db-data:/root/var/data
    command: yugabyted start --listen 0.0.0.0 --background=false --tserver_flags="yb_enable_read_committed_isolation=true,ysql_colocate_database_by_default=false"

  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5433
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "80:3000"

volumes:
  db-data:
Enter fullscreen mode Exit fullscreen mode

In this version of YugabyteDB (2.19) the read-commited behavior is not enabled by default (compatibility with previous versions which implemented only repetable read and serializable) and that's why I pass an additional flag. Colocated can be set to true when testing a new application to decide later which tables needs to be distributed.

I start YugabyteDB first:

docker compose up -d db
Enter fullscreen mode Exit fullscreen mode

Starting with yugabyted start is the easiest but takes a few seconds to check everything. That's why I start it first and try to connect until I've no could not connect to server. The goal is to test it. It can be optimized for automated tests and for production where, anyway, you start multiple nodes as the database is distributed.

Here is how I check that the database is ready for connections:

until
docker compose exec -i db bash -c 'PGPASSWORD=wikijsrocks ysqlsh -d wiki -U wikijs -c "show server_version"'
do sleep 1 ; done

Enter fullscreen mode Exit fullscreen mode

11.2-YB-2.19.0.0-b0

I can start the remaining service:

docker compose up -d
Enter fullscreen mode Exit fullscreen mode

Image description

If it takes longer than with PostgreSQL to create the schema, this can be optimized. The default waits after index creation to do it online, without locks, and I used all default settings here to make it simple.

I can use the application:
Image description

Image description

Of course, this is not sufficient to run into production. You should test the application. Maybe the default sharding method is not optimal and some indexes may be changed to get the best performance.

If you have any issue, please contact the YugabyteDB community on Slack, Forum, GitHub or our Community Open Hours.

Top comments (0)