Startup configuration file

It would be useful if there was a configuration file to specify default options, such as --certs-dir, --locality, --store options, --attr and probably others. Perhaps a default location, such as …/etc/cockroach.conf with an option to specify the config location.

Obvious work around is to use a startup script…

Not having a config file is one of the advantages, it keeps setup much simpler and avoids the need to manage some other file.

What does having a config file solve that isn’t possible right now?

Not having a config file means you have to add command line parameters to the cockroach command, or possibly set environment variables. This leads to errors (typos), non consistent startup parameters, etc… Those parameters added to any script that invokes cockroach (creates multiple touch points) and is basically less maintainable and scale-able. Things can be done such as creating a source file that other scripts include which sets up aliases, but that is a kludge compared to a configuration file.

@jlauro We have gotten this request from several users of CockroachDB. Currently, we suggest using a startup script as you suggested as a workaround. Our philosophy is to keep things simple by not requiring config files, but that may change as we get more feedback on how to make the CockroachDB experience better.

One reason we’re trying to avoid a config file is that in most cases, you want settings to apply cluster-wide (we’re introducing a new SET CLUSTER SETTING command in the upcoming release). Config files make it possible for different nodes to have different configurations. We only want to allow that for options that legitimately need to be different between nodes (where does the data live? how much memory can be used for caches?). Since there are only a few such options, we feel like command-line flags are a more appropriate solution than a config file (or in other words, your startup script is your config file).


This is a strange situation when dealing with databases - crdb itself is meant to store data, in a reliable, available and distributed fashion. Why use configs stored in fragile files when the database cluster itself can store all the settings and make sure everything is consistent while being easy to query and update?

It’s much nicer in our experience to just have a new node join the cluster and find out everything it needs rather than tweaking configs and having the same settings everywhere, something that most other databases get wrong.

@ManiGandham It is very strange to reference using the DB to store configuration items, when those configuration items are needed in order to access the database, and when those things can not be altered after the database is started. Specifically things such as certificate locations, storage location, locality settings, all of which have to be defined outside the database. Why not use config files for those things, as command line options are even more fragile than configuration files? Configuration files are easier to put under automated deployment routines, etc… (Not a serious impediment as I can replace cockroach with a shell script that reads a config file and executes the rename cockroach executable, just pointing out your arguments against configuration files are invalid as you can’t use the database to store configrations.)


For cluster-wide settings, using the database itself is better than repeating them across files.

For everything that’s specific to that node or needed to actually start (which isn’t much in this case), what’s the difference between a command argument pointing to a file that has settings vs just having all the settings as command arguments?

Whatever you use to create a config file can be used to generate a shell script with command arguments instead.

Personally I’m very happy and impressed with the simplicity of using cockroachdb.

Only a single statically linked executable to deal with.

No configuration file to deal with.

Few simple options.

Great stuff.

If one really wants a config file then make one and put the command line parameters into it. Then:

$ cockroach $(cat config)


Is there any way setting global “TIME ZONE” settings - I want to change time zone to other than the default but it seems session based but not global I suspect.

Without config file how that would be achieved?


Am struggling setting of TimeZone as IST, but failed to get that - Any link anybody can suggest if doesn’t want to response here?

Cockroach defers’s to go’s implementation of timezones, which is pulls zone info from the OS, so it may vary from machine to machine as to why that may have failed.

I’m actually not entirely sure of the cause of this, but the short timezone identifiers (EST, IST ,etc.) only seem to work for some timezones. Specifying a timezone via location is generally more consistent. For instance, to get your timezone to be IST (GMT +5:30), you should be able to do:

SET TIME ZONE 'Asia/Kolkata';

Yes, having a startup configuration is required to be there for a database service to start with all older settings.

Short timezone identifiers like IST only work when they are unique. India, Ireland, and Israel all use “IST”, so it can’t know which one you want. Place names are less ambiguous: Asia/Kolkata, Europe/Dublin, and Asia/Jerusalem.

Thanks BDarenell,

It is fine setting “Asia/Kolkata” for me (I hope you are pointing it to set in application’s code-base) but I wanted to have it set in any configuration file somewhere to simply the service-restart process.

Any luck using startup-configuration file.


Configuration files are tricky in a distributed system - what happens if different nodes have different configurations? Something stored in the database itself (like our SET CLUSTER SETTING command is better, since it will be consistent across all nodes, but there are some difficulties with using this safely for time zones. I think the best long-term solution for this is the ALTER USER command, which can be used in postgres to set a time zone for a user whenever that user connects. This is tracked in

In the meantime, you’ll just need to explicitly issue a SET TIME ZONE command at the start of each session (or do your time manipulations in client-side code instead of in the database).

Hey there,

Settings it in this way may set it for a particular session, what if any code has been left without setting the session level settings.

Having config file will only solve the case for global settings - Can we please know if we may use configuration file OR the way how can I set global TIME ZONE settings on the start up of database node?

Many thanks

At this time the session variable is the only way to set the time zone. Follow issue 16029 for updates.

How could we use ALTER USER command there on SQL console, Is this command exist, following execution is getting failed on SQL console?

ALTER USER XXXXXX SET timezone=‘Asia/Kolkata’;


The ALTER USER SET TIMEZONE command is not yet implemented.