Goose database migration tool - fork of https://bitbucket.org/liamstask/goose

Overview

goose

Goose is a database migration tool. Manage your database schema by creating incremental SQL changes or Go functions.

GoDoc Widget Travis Widget

Goals of this fork

github.com/pressly/goose is a fork of bitbucket.org/liamstask/goose with the following changes:

  • No config files
  • Default goose binary can migrate SQL files only
  • Go migrations:
    • We don't go build Go migrations functions on-the-fly from within the goose binary
    • Instead, we let you create your own custom goose binary, register your Go migration functions explicitly and run complex migrations with your own *sql.DB connection
    • Go migration functions let you run your code within an SQL transaction, if you use the *sql.Tx argument
  • The goose pkg is decoupled from the binary:
    • goose pkg doesn't register any SQL drivers anymore, thus no driver panic() conflict within your codebase!
    • goose pkg doesn't have any vendor dependencies anymore
  • We use timestamped migrations by default but recommend a hybrid approach of using timestamps in the development process and sequential versions in production.

Install

$ go get -u github.com/pressly/goose/cmd/goose

This will install the goose binary to your $GOPATH/bin directory.

For a lite version of the binary without DB connection dependent commands, use the exclusive build tags:

$ go build -tags='no_postgres no_mysql no_sqlite3' -i -o goose ./cmd/goose

Usage

Usage: goose [OPTIONS] DRIVER DBSTRING COMMAND

Drivers:
    postgres
    mysql
    sqlite3
    mssql
    redshift

Examples:
    goose sqlite3 ./foo.db status
    goose sqlite3 ./foo.db create init sql
    goose sqlite3 ./foo.db create add_some_column sql
    goose sqlite3 ./foo.db create fetch_user_data go
    goose sqlite3 ./foo.db up

    goose postgres "user=postgres dbname=postgres sslmode=disable" status
    goose mysql "user:[email protected]/dbname?parseTime=true" status
    goose redshift "postgres://user:[email protected]:5439/db" status
    goose tidb "user:[email protected]/dbname?parseTime=true" status
    goose mssql "sqlserver://user:[email protected]:1433?database=master" status

Options:

  -dir string
    	directory with migration files (default ".")
  -table string
    	migrations table name (default "goose_db_version")
  -h	print help
  -v	enable verbose mode
  -version
    	print version

Commands:
    up                   Migrate the DB to the most recent version available
    up-by-one            Migrate the DB up by 1
    up-to VERSION        Migrate the DB to a specific VERSION
    down                 Roll back the version by 1
    down-to VERSION      Roll back to a specific VERSION
    redo                 Re-run the latest migration
    reset                Roll back all migrations
    status               Dump the migration status for the current DB
    version              Print the current version of the database
    create NAME [sql|go] Creates new migration file with the current timestamp
    fix                  Apply sequential ordering to migrations

create

Create a new SQL migration.

$ goose create add_some_column sql
$ Created new file: 20170506082420_add_some_column.sql

Edit the newly created file to define the behavior of your migration.

You can also create a Go migration, if you then invoke it with your own goose binary:

$ goose create fetch_user_data go
$ Created new file: 20170506082421_fetch_user_data.go

up

Apply all available migrations.

$ goose up
$ OK    001_basics.sql
$ OK    002_next.sql
$ OK    003_and_again.go

up-to

Migrate up to a specific version.

$ goose up-to 20170506082420
$ OK    20170506082420_create_table.sql

up-by-one

Migrate up a single migration from the current version

$ goose up-by-one
$ OK    20170614145246_change_type.sql

down

Roll back a single migration from the current version.

$ goose down
$ OK    003_and_again.go

down-to

Roll back migrations to a specific version.

$ goose down-to 20170506082527
$ OK    20170506082527_alter_column.sql

redo

Roll back the most recently applied migration, then run it again.

$ goose redo
$ OK    003_and_again.go
$ OK    003_and_again.go

status

Print the status of all migrations:

$ goose status
$   Applied At                  Migration
$   =======================================
$   Sun Jan  6 11:25:03 2013 -- 001_basics.sql
$   Sun Jan  6 11:25:03 2013 -- 002_next.sql
$   Pending                  -- 003_and_again.go

Note: for MySQL parseTime flag must be enabled.

version

Print the current version of the database:

$ goose version
$ goose: version 002

Migrations

goose supports migrations written in SQL or in Go.

SQL Migrations

A sample SQL migration looks like:

-- +goose Up
CREATE TABLE post (
    id int NOT NULL,
    title text,
    body text,
    PRIMARY KEY(id)
);

-- +goose Down
DROP TABLE post;

Notice the annotations in the comments. Any statements following -- +goose Up will be executed as part of a forward migration, and any statements following -- +goose Down will be executed as part of a rollback.

By default, all migrations are run within a transaction. Some statements like CREATE DATABASE, however, cannot be run within a transaction. You may optionally add -- +goose NO TRANSACTION to the top of your migration file in order to skip transactions within that specific migration file. Both Up and Down migrations within this file will be run without transactions.

By default, SQL statements are delimited by semicolons - in fact, query statements must end with a semicolon to be properly recognized by goose.

More complex statements (PL/pgSQL) that have semicolons within them must be annotated with -- +goose StatementBegin and -- +goose StatementEnd to be properly recognized. For example:

-- +goose Up
-- +goose StatementBegin
CREATE OR REPLACE FUNCTION histories_partition_creation( DATE, DATE )
returns void AS $$
DECLARE
  create_query text;
BEGIN
  FOR create_query IN SELECT
      'CREATE TABLE IF NOT EXISTS histories_'
      || TO_CHAR( d, 'YYYY_MM' )
      || ' ( CHECK( created_at >= timestamp '''
      || TO_CHAR( d, 'YYYY-MM-DD 00:00:00' )
      || ''' AND created_at < timestamp '''
      || TO_CHAR( d + INTERVAL '1 month', 'YYYY-MM-DD 00:00:00' )
      || ''' ) ) inherits ( histories );'
    FROM generate_series( $1, $2, '1 month' ) AS d
  LOOP
    EXECUTE create_query;
  END LOOP;  -- LOOP END
END;         -- FUNCTION END
$$
language plpgsql;
-- +goose StatementEnd

Go Migrations

  1. Create your own goose binary, see example
  2. Import github.com/pressly/goose
  3. Register your migration functions
  4. Run goose command, ie. goose.Up(db *sql.DB, dir string)

A sample Go migration 00002_users_add_email.go file looks like:

package migrations

import (
	"database/sql"

	"github.com/pressly/goose"
)

func init() {
	goose.AddMigration(Up, Down)
}

func Up(tx *sql.Tx) error {
	_, err := tx.Exec("UPDATE users SET username='admin' WHERE username='root';")
	if err != nil {
		return err
	}
	return nil
}

func Down(tx *sql.Tx) error {
	_, err := tx.Exec("UPDATE users SET username='root' WHERE username='admin';")
	if err != nil {
		return err
	}
	return nil
}

Hybrid Versioning

Please, read the versioning problem first.

We strongly recommend adopting a hybrid versioning approach, using both timestamps and sequential numbers. Migrations created during the development process are timestamped and sequential versions are ran on production. We believe this method will prevent the problem of conflicting versions when writing software in a team environment.

To help you adopt this approach, create will use the current timestamp as the migration version. When you're ready to deploy your migrations in a production environment, we also provide a helpful fix command to convert your migrations into sequential order, while preserving the timestamp ordering. We recommend running fix in the CI pipeline, and only when the migrations are ready for production.

License

Licensed under MIT License

Comments
  • sequential numbering with postgres or redshift schemas

    sequential numbering with postgres or redshift schemas

    I'm just started using this fork because it has support for Redshift. However, I use schemas to organize tables with databases like redshift and postgres but the new sequential numbering of files, instead of timestamps, means that I have to put all my migration files in the same directory, otherwise the counter will start again at 00001 for each directory.

    Say I have a single database in redshift or postgres, and it has multiple schemas CREATE SCHEMA foo; and CREATE SCHEMA bar;. If I wanted to organize my goose migrations by folders, I might have:

    foo/
    bar/
    

    If i then ran cd foo && goose create add_cars sql then cd ../bar && goose_create add_trains sql, goose will create foo/00001_add_cars.sql and bar/00001_add_trains.sql. So running:

    $ cd foo $ goose postgres "user=rkulla dbname=postgres sslmode=disable" up goose: no migrations to run. current version: 1 $ cd ../bar $ goose postgres "user=rkulla dbname=postgres sslmode=disable" up goose: no migrations to run. current version: 1

    would only apply the migration under foo/ but not the one under bar/, because both migrations start with 00001_ and postgres or redshift only get ONE goose_db_version table to share amongst the different schema names. This makes them harder to organize unless I do goose create add_cars_foo sql' andgoose create add_trains_bar sql, then run commands likels *_foo.sqlandls *_bar.sql`.

    It's not that big of a deal right now I guess, but I'm wondering if there's a better way and if it's really worth not using timestamps. IIRC, Ruby on Rails's migration feature used to use sequential numbers but developers complained because it caused a lot of conflicts when 2 different developers working on the same project made separate changes but both generated a migration with the same number. So Rails switched to UTC timestamps.

    opened by rkulla 28
  • Exit the program when migration can't be parsed

    Exit the program when migration can't be parsed

    Closes #115

    With un-parsable SQL, goose should exit it's current execution.

    Previously, goose would effectively skip over this invalid migration but still mark it as applied on the database.

    This PR will make it so that goose will error out of it's current execution and the migration will not be applied.

    I have also added files created by tests to the .gitignore

    opened by TomasBarry 24
  • Add support for seeding the database with test data

    Add support for seeding the database with test data

    I have used goose at pretty much every job to manage my relational databases. It works like a charm, but I always find myself creating some sort of wrapper that allows me to use goose to seed my local and development environments with test data. It would be really nice if this were supported already.

    I propose creating a new command goose seed that will allow users to continue managing their schema migrations with goose and also seed their non-production environments with test data for integration & end-to-end testing. Please note that I am not suggesting actual seed data be managed this way - if your application requires some static, pre-existing data, that can just be inserted along with the regular schema migrations.

    What are your thoughts on this? If we agree that this is useful and decide on an interface, I'd like to take on this work and open a PR to implement it.

    opened by soggycactus 23
  • Add vendoring support using dep vendor package manager.

    Add vendoring support using dep vendor package manager.

    • Add vendor dependencies for better macos homebrew support
    • Referencing #42
    • Referencing Homebrew/homebrew-core#14724

    Signed-off-by: Mario Kozjak [email protected]

    opened by mkozjak 22
  • error: `CREATE INDEX CONCURRENTLY` cannot run inside a transaction block

    error: `CREATE INDEX CONCURRENTLY` cannot run inside a transaction block

    Hi, I am getting the following error whenever I am trying to create indexes separately:

    failed to run SQL migration: failed to execute SQL query "..."
    pq: CREATE INDEX CONCURRENTLY cannot run inside a transaction block
    

    Here's a small reproduction of my table migration:

    -- +goose Up
    -- +goose StatementBegin
    CREATE TABLE users (
        id UUID NOT NULL PRIMARY KEY DEFAULT gen_random_uuid(),
        email VARCHAR NOT NULL,
        username VARCHAR NOT NULL
    );
    
    CREATE INDEX CONCURRENTLY users_id_pkey ON users(id);
    CREATE UNIQUE INDEX CONCURRENTLY users_email_key ON users(email);
    CREATE UNIQUE INDEX CONCURRENTLY users_username_key ON users(username);
    -- +goose StatementEnd
    

    Is there any way to fix this, or should I move each index creation query to a separate migration file?

    opened by michaelgrigoryan25 15
  • Avoid to ignore empty lines in SQL files

    Avoid to ignore empty lines in SQL files

    The current implementation ignores blank lines in the migration sql file.

    But in my use case, this behavior produced unexpected results. In some cases, a blank line in the SQL may be meaningful. The following code is an example of SQL using the E string syntax in PostgreSQL.

    INSERT INTO article (id, content) VALUES ('id_0001',  E'# My markdown doc
    
    first paragraph
    
    second paragraph');
    

    In this markdown text, empty lines must NOT be removed.

    As far as I could check, the same behavior was not observed in command line mode. it occurs only in the case of library use. Therefore, If there is no strong motivation to ignore blank lines, this behavior should be fixed.

    I would love to hear your opinion. Thanks for the great library.

    opened by iktakahiro 11
  • goose is no longer able to run with GOOSE_DBSTRING set as env

    goose is no longer able to run with GOOSE_DBSTRING set as env

    I have not added or changed anything but did not pin the version of goose.

    In the latest version I am now unable to set this env variable. Therefore I am unable to get the correct env string for deployments. Which ultimately messes up production issues now.

    goose run: "postgres": no such command
    

    I am running this command:

    ./goose -dir migrations postgres $GOOSE_DBSTRING up 
    
    opened by eleijonmarck 10
  • Binary releases

    Binary releases

    Hi all,

    First off - thanks for stepping up and taking over this project!

    I'd love to see binary releases published to your GitHub repo. Doing a go get to grab the CLI at runtime is a little scary, since we can't pin a version (to my knowledge). Even scarier given that this is mucking with databases.

    In terms of implementation, we're big fans of goreleaser - it does all the heavy lifting for you.

    Would be happy to take a crack at a PR if y'all would be open to it.

    opened by rbren 9
  • goose run: no separator found

    goose run: no separator found

    I've installed the binary using go get -u github.com/pressly/goose/cmd/goose. I can generate the migration files in anywhere, but not in my project directory. When i type something like goose postgres <connection_string> status, i got error goose run: no separator found. Is there something i might misconfigure ? or misunderstand the usage ? thanks

    I'm using

    • golang:1.9.2 darwin/amd64
    • macOS High Sierra 10.13
    opened by pjuanda 9
  • Feature Request: Custom migration templates

    Feature Request: Custom migration templates

    Hi,

    If I'm willing to create a PR, would you be open to adding an option to allow us to specify custom templates?

    The reason I ask is that the current sql template produces:

    
    -- +goose Up
    -- SQL in section 'Up' is executed when this migration is applied
    
    
    -- +goose Down
    -- SQL section 'Down' is executed when this migration is rolled back
    
    
    

    but I would like it to produce:

    
    -- +goose Up
    -- +goose StatementBegin
    -- +goose StatementEnd
    
    
    -- +goose Down
    -- +goose StatementBegin
    -- +goose StatementEnd
    
    
    

    I want to always use the begin and end statements since we will be doing some complex migrations including plpgsql functions and I'd rather just always use the same format.

    Allowing me to specify a custom template would avoid me having to replace the default template in the newly-created file after creating a new migration.

    If you're open to this, please give me a suggestion as to how you'd like the template specified and I'd be happy to follow that. I guess I'd see these templates specified in code, but I suppose a command like arg would work as well.

    Thoughts?

    Thanks!

    opened by joelpresence 9
  • feature request: goto VERSION (which may go up or down depending on the current and supplied version)

    feature request: goto VERSION (which may go up or down depending on the current and supplied version)

    Hello! I just wanted to ask if you have considered adding a goto VERSION command which may go up or down depending on the current and supplied versions?

    If this is something you would consider, I could perhaps try to make a PR for it.

    Thank you!

    opened by craigpastro 8
  • Bump modernc.org/sqlite from 1.18.1 to 1.19.1

    Bump modernc.org/sqlite from 1.18.1 to 1.19.1

    Bumps modernc.org/sqlite from 1.18.1 to 1.19.1.

    Commits
    • 99d1113 support freebsd/arm64.3
    • 1b683ac support freebsd/arm64.2
    • fd7b2cc support freebsd/arm64
    • af5809d freebsd/arm: generate
    • eff53ef upgrade to SQLite 3.39.3
    • 16f30d5 README: fix go-sqlite3 URL
    • e255a82 Merge branch 'master' into 'master'
    • ed662f2 add explanatory sentence of mattn/go-sqlite3 dependency
    • 4bb7d8e Merge branch 'master' into 'master'
    • 8f692c9 migrate from deprecated ioutil package
    • See full diff in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies go 
    opened by dependabot[bot] 0
  • Could we have an option not to generate color escape sequences in goose output (ex: -no-color)

    Could we have an option not to generate color escape sequences in goose output (ex: -no-color)

    Right now (using v3.6.1)

    ''' 2022/09/19 14:29:39 -- +goose Up 2022/09/19 14:29:39 StateMachine: 0 => 1 ------------ We see [90m and [00m codes in there and makes the logs more difficult to read - ex: in Jenkins job logs, etc. 2022/09/19 14:29:39 insert into ... '''

    opened by callaingit 0
  • -no-versioning and -table options seem not to work

    -no-versioning and -table options seem not to work

    I have 2 different directories

    1. ./resources/db/migrations/       
    ├── 00001_create_a.sql
    ├── 00002_create_b.sql
    ├── 00003_create_c.sql
    ├── 00004_create_d.sql
    ├── 00005_create_e.sql
    ├── 00006_create_f.sql
    └── 00007_create_g.sql
    2. ./resources/db/seed/
    ├── 00001_seed_a.sql
    ├── 00002_seed_b.sql
    ├── 00003_seed_c.sql
    └── 00004_seed_d.sql
    

    I would like to seed the data from goose command line.

    As you can see the versions of seed and migrations are different and are not in sync. I am not able to seed data from command line based on documentation.

    I've used

    -table,

    but It doesn't do anything, It doesn't create a new table, as I was expecting

    -no-versioning

    Doesn't work at all, I don't know why is it even there. It doesn't redo last available migration in seed directory, nor does it give correct error. I tried redo with -no-versioning, doesn't work, I tried down-to and up-to , doesn't work.

    My question at this point is, How can I initialize a new versioning table for seeds in db using goose cli? I don't want to manually run a create table command in db,

    opened by insanebaba 2
  • -allow-missing does not seem to be handled properly when followed by a down-to or down command?

    -allow-missing does not seem to be handled properly when followed by a down-to or down command?

    Using goose v3.6.1 with mysql

    We applied a missing script that we inserted midway using -allow-missing option

    | 3020 | 20220729193614 |          1 | 2022-07-29 19:47:52 |
    | 3021 | 20220729193639 |          1 | 2022-07-29 19:47:52 |
    | 3022 | 20220729193704 |          1 | 2022-07-29 19:47:52 |
    | 3026 | 20220801203535 |          1 | 2022-08-02 17:46:23 |
    | 3027 | 20220729140600 |          1 | 2022-08-31 14:38:16 | <-- Last row has version 20220729140600, but it's not the highest version that we executed...
    

    Afterwise, the current version (as reported with version) is 20220729140600, which seems a bit odd to us (shall it be 20220801203535 instead)?

    Now, when we use goose down-to commands, goose seems to start with that version going down and of course, that does not work as scripts after 20220729140600 will prevent down scripts from 20220729140600 to complete...

    We had expected goose to consider the latest version being the last applied row being ordered by latest version_id descending, not id descending (or at least ordered by version_id, id descending).

    Seems like the goose reset command is our only hope, but it removes all migrations...

    Was this the expected behavior (implies that "down-to 0" is not the same as "reset" if one has run missing migrations)? If so, can this be clarified somewhere in the docs/blog? If not, can it be fixed?

    Thanks.

    opened by callaingit 10
  • migrations statuses func

    migrations statuses func

    Hi! Someone asked in #255 about having function for getting migration statuses.

    So if you want to have this func we can discuss it, because I have some thoughts additionally to the changes.

    1. looks like the Migrations type should have this function
    func (ms Migrations) Records() ([]MigrationRecord, error) {}
    
    1. add a tstamp to query in dbVersionQuery(db *sql.DB) in case that someone needs it.
    opened by w1kend 0
Releases(v3.7.0)
Owner
Pressly Inc.
Pressly Inc.
It's a Go console utility for migration from MSSQL to MySQL engine.

A tool for migration the databases to MySQL It's a Go console utility for migration from MSSQL to MySQL engine. The databases should have prepopulated

Eugen Vasilyeu 0 Jan 4, 2022
A fully-featured AWS Athena database driver (+ athenareader https://github.com/uber/athenadriver/tree/master/athenareader)

?? athenadriver - A fully-featured AWS Athena database driver for Go ?? athenareader - A moneywise command line utililty to query athena in command li

Uber Open Source 113 Sep 9, 2022
[mirror] the database client and tools for the Go vulnerability database

The Go Vulnerability Database golang.org/x/vulndb This repository is a prototype of the Go Vulnerability Database. Read the Draft Design. Neither the

Go 163 Sep 24, 2022
Database - Example project of database realization using drivers and models

database Golang based database realization Description Example project of databa

Denis 1 Feb 10, 2022
🏋️ dbbench is a simple database benchmarking tool which supports several databases and own scripts

dbbench Table of Contents Description Example Installation Supported Databases Usage Custom Scripts Troubeshooting Development Acknowledgements Descri

Simon Jürgensmeyer 74 Sep 26, 2022
Dumpling is a fast, easy-to-use tool written by Go for dumping data from the database(MySQL, TiDB...) to local/cloud(S3, GCP...) in multifarious formats(SQL, CSV...).

?? Dumpling Dumpling is a tool and a Go library for creating SQL dump from a MySQL-compatible database. It is intended to replace mysqldump and mydump

PingCAP 266 Sep 19, 2022
The EVEmu Database Tool

EVEDBTool - The EVEmu Database Tool This is a tool written in Go to manage the installation, versioning and update of the EVEmu database. A pre-built

EvEmu Project 4 Feb 9, 2022
A little database tool for version control

A little database tool for version control It's very like sqitch, because I imitate it. If it's not allowed, give me a message, I'll destroy this proj

null 8 Aug 18, 2022
A tool I made to quickly store bug bounty program scopes in a local sqlite3 database

GoScope A tool I made to quickly store bug bounty program scopes in a local sqlite3 database. Download or copy a Burpsuite configuration file from the

null 3 Nov 18, 2021
A database connection tool for sensitive data

go-sql 用于快速统计数据库行数、敏感字段匹配、数据库连接情况。 usage ./go-sql_darwin_amd64 -h ./go-sql_darwin_amd64 -f db.yaml -k name,user ./go-sql_darwin_amd64 -f db.yaml --min

null 5 Apr 4, 2022
Web-based, zero-config, dependency-free database schema change and version control tool for teams

Live Demo • Install • Help • Development • Design Doc Bytebase is a web-based, zero-config, dependency-free database schema change and version control

Bytebase 3.9k Sep 17, 2022
Database wrapper that manage read write connections

rwdb Database wrapper that manage read write connections Install go get github.com/andizzle/rwdb Create connections package main import "github.com/

Andy Zhang 15 Aug 5, 2022
Vitess is a database clustering system for horizontal scaling of MySQL.

Vitess Vitess is a database clustering system for horizontal scaling of MySQL through generalized sharding. By encapsulating shard-routing logic, Vite

Vitess 14.7k Sep 20, 2022
sqlx is a library which provides a set of extensions on go's standard database/sql library

sqlx is a library which provides a set of extensions on go's standard database/sql library. The sqlx versions of sql.DB, sql.TX, sql.Stmt, et al. all leave the underlying interfaces untouched, so that their interfaces are a superset on the standard ones. This makes it relatively painless to integrate existing codebases using database/sql with sqlx.

Jason Moiron 12.6k Sep 22, 2022
Convert data exports from various services to a single SQLite database

Bionic Bionic is a tool to convert data exports from web apps to a single SQLite database. Bionic currently supports data exports from Google, Apple H

Bionic 142 Sep 22, 2022
Zero boilerplate database operations for Go

(Now compatible with MySQL and PostgreSQL!) Everyone knows that performing simple DATABASE queries in Go takes numerous lines of code that is often re

null 349 Sep 15, 2022
Vitess is a database clustering system for horizontal scaling of MySQL.

Vitess Vitess is a database clustering system for horizontal scaling of MySQL through generalized sharding. By encapsulating shard-routing logic, Vite

Vitess 14.8k Sep 26, 2022
Additions to Go's database/sql for super fast performance and convenience.

gocraft/dbr (database records) gocraft/dbr provides additions to Go's database/sql for super fast performance and convenience. $ go get -u github.com/

null 1.7k Sep 14, 2022